Python Network Automation: When to Use Objects vs REST APIs

Introduction

Python network automation often begins with a small script that sends a request, receives JSON, and applies a change. That model is effective for focused tasks. As automation expands into service portals, CI/CD pipelines, provisioning systems, and workflow engines, the code also has to coordinate state, relationships, policy, retries, and verification.

In the real world, a maintainable network automation architecture must separate business intent from transport details. A Python API integration may begin with one API call, but larger automation workflows need reusable policy, predictable error handling, and a reliable view of network infrastructure.

The important architectural question is therefore not whether objects or REST APIs are universally better. It is where each approach reduces complexity and makes the intended operation easier to understand.

EfficientIP’s 2019 introduction to the SOLIDserver Python library described both direct service mapping and an advanced object model. This article focuses on the broader design decision. The object-oriented DDI automation solution note provides the detailed SOLIDserver implementation.

Key Takeaways

• Use objects when automation works with resource state, relationships, and lifecycle operations.
• Use direct REST calls for focused queries, filtered result sets, and specialized endpoints.
• Keep both options behind a shared session and consistent operational controls.
• Add abstractions only when they make several workflows clearer, not merely to hide endpoint names.

Why the Abstraction Choice Matters

A REST API exposes operations offered by a remote system. A Python object represents a concept inside the automation application. Those are related, but they are not the same thing.

REST API automation sends HTTP requests to an API endpoint and interprets the requests and responses. A client typically manages the base URL, authentication, query parameters or POST requests, each returned status code, and the retrieved data. This visibility is useful, but repeating the same transport logic across many workflows can obscure the operational intent.

An API request may ask a platform to list interfaces, update a route, create an address object, or return utilization data. The request is explicit and usually maps closely to the platform’s service model. This makes direct calls easy to trace and useful when the application needs one well-defined operation.

Object-oriented Python instead groups data and behavior around a resource such as a device, interface, network, zone, policy, or cloud segment. The object can retain an identifier and current state, expose validation, represent relationships, and provide lifecycle methods such as create, refresh, update, or delete.

The object approach becomes valuable when a workflow performs several related actions. Without it, identifiers, validation rules, response parsing, and relationship logic can spread across many functions. With it, the application can reason about a resource rather than repeatedly reconstructing its context.

Neither approach removes the underlying API. The choice concerns how much of the remote service model should be translated into the application’s domain model.

Objects and Direct REST Calls Solve Different Problems

Use objects for resource-oriented workflows

Objects are usually the clearer choice when the automation needs to:

• Read and retain the current state of a resource
• Navigate parent-child or peer relationships
• Apply several lifecycle operations to the same resource
• Enforce reusable validation or policy
• Present a stable application interface across several workflows

For example, a device object could retain the device identifier, load its current interfaces, validate a proposed change, and apply an update. The calling workflow does not need to pass the same identifiers and context through every function.

Use REST APIs for focused operations

A direct call is often clearer when the automation needs to:

• Run a filtered inventory or reporting query
• Invoke one specialized service operation
• Access a new endpoint that an object library does not yet expose
• Process a result set without maintaining individual resource objects
• Keep a short, infrequently used task close to the API documentation

Direct API requests are particularly useful when a monitoring or reporting task needs fresh operational information in real time. Most network management web services already expose focused search, list, and reporting operations for that purpose.

Creating an object for every row returned by a reporting query may add work without adding meaning. In that case, a single filtered request and a normalized response can be the simpler design.

Combine both in one workflow

Most mature integrations need both patterns. A workflow may use objects to manage resources with state and relationships, then use a direct API call to retrieve a filtered report or invoke a specialized function. A shared session can centralize authentication, TLS settings, timeouts, retries, and error handling for both.

This principle applies whether the client is an open source library, a vendor SDK, or an internally developed service layer. The hybrid model avoids two unhelpful extremes: forcing every operation into an object hierarchy, or leaving all domain logic scattered across raw request functions.

A Five-Question Decision Framework

Use these questions when deciding how to represent an operation.

1. Does the workflow maintain state across several steps?

Prefer an object when later actions depend on information loaded or created earlier. A resource instance provides a clear place for the identifier, current state, and relevant behavior.

2. Are relationships central to the operation?

Objects help when the workflow must express containment, ownership, dependencies, or hierarchy. Examples include a network inside a routing domain, an interface on a device, or a policy attached to a group.

3. Is the task one focused request or a filtered read?

A direct REST call is often sufficient for counts, search, inventory, reporting, and narrowly scoped actions. Wrapping the request may make the code longer without improving its intent.

4. Is the API surface changing faster than the object library?

Keep a direct-call escape hatch. It allows automation to use newly introduced or uncommon endpoints without waiting for a new object wrapper.

5. Will several workflows reuse the same rules?

An object, service class, or reusable wrapper becomes valuable when multiple workflows repeat the same validation, state transitions, or error handling. Reuse—not the existence of an endpoint—is the stronger reason to add an abstraction.

Structuring a Hybrid Python Automation Layer

A maintainable design separates four concerns:

1. Session and transport: Authentication, certificate validation, timeouts, retries, serialization, and low-level errors.
2. Domain objects: Resource state, relationships, validation, and lifecycle behavior.
3. Direct service access: A controlled method for focused or unsupported API operations.
4. Workflow orchestration: Business policy, approvals, sequencing, structured input and output, and integration with external systems.

The following illustrative pseudocode shows the separation:

api = ApiSession(configuration)

resource = NetworkResource(api=api, resource_id=resource_id)
resource.refresh()
resource.apply(desired_state)

report = api.query(
    "filtered_inventory",
    params=filters,
)

The object handles a stateful resource operation. The direct query handles a filtered result set. Both use the same connection and transport controls.

Well-designed automation solutions keep these layers observable without exposing transport details throughout the business logic. Validation and approval gates can reduce human error before a write reaches the target platform, while logs give network operations teams enough context to troubleshoot failures.

This separation also improves automation testing. Domain behavior can be tested with mocked API responses, while a smaller set of integration tests verifies the actual service contracts. Workflow tests can then focus on policy and sequencing rather than low-level HTTP details.

Common Design Mistakes

Wrapping every endpoint

An object method that simply renames an API operation may not provide a useful abstraction. Add a wrapper when it centralizes validation, state, relationships, error handling, or repeated logic.

Hiding remote behavior completely

Network automation still depends on distributed systems. Rate limits, asynchronous processing, partial failures, and API-specific errors do not disappear because the code uses objects. Preserve enough information for troubleshooting and audit.

Treating object state as permanently current

A local object is a representation of remote state at a point in time. Long-running workflows should define when to refresh state, how to detect conflicts, and what to do when another process changes the resource.

Duplicating policy in every layer

Keep business rules in one deliberate layer. If both the workflow and every object independently implement the same selection or approval logic, behavior becomes harder to test and change.

How the Pattern Maps to DDI

DDI provides a useful example because network spaces, subnets, addresses, DNS zones, and records have identifiable state and relationships. An object model can represent those resources, while direct API calls remain useful for filtered inventory, reporting, verification, or specialized services.

The SOLIDserver Python implementation uses this hybrid structure. The SOLIDserverRest project provides direct API mapping, while its advanced model adds resource-oriented classes.

The detailed code, methods, provisioning sequence, and operational considerations belong in the object-oriented DDI automation solution note. The SOLIDserver Python automation demo shows the workflow in action, and the Python demonstration scripts on GitHub provide the corresponding reference code.

More broadly, the SOLIDserver API for IT automation enables DDI operations to participate in service portals, orchestration, infrastructure provisioning, and other ecosystem workflows.

Conclusion

Python network automation does not need to choose between object-oriented code and direct REST APIs. Objects are well suited to resources whose state, relationships, and lifecycle matter. Direct calls remain efficient for focused, filtered, specialized, or newly introduced operations.

The strongest architecture keeps both options available behind consistent transport and operational controls. Teams can then add abstractions where they improve reuse and clarity, while retaining direct API access where an additional object layer would add little value.