Factor out duplication between synchronous and asynchronous clients

[vblagoje]

Description

Currently, there is duplicated logic in openapi_llm/client/openapi.py (synchronous) and openapi_llm/client/openapi_async.py (asynchronous). Both files share similar code paths for building requests, extracting payloads, and handling authentication. This duplication increases maintenance overhead and makes it more difficult to keep features in sync.

Why It Matters

• Maintaining two code paths can lead to inconsistencies.
• Potential bugs and missing features in one client if it’s not updated consistently.
• Refactoring to share code would streamline future development.

Proposed Solution

• Introduce a common utility module (e.g., openapi_llm/client/_common.py) that encapsulates:

  • Request-building logic
  • Payload extraction
  • Authentication application
  • Shared error-handling routines

• Synchronous and Asynchronous clients would each import and call these shared functions, differing only by the HTTP transport logic (i.e., requests vs. aiohttp).

• Keep public classes OpenAPIClient and AsyncOpenAPIClient but reduce them to minimal wrappers around the shared logic.

Acceptance Criteria

• Synchronous and asynchronous clients reference a single shared code path for building and invoking requests.
• No or minimal duplication remains in openapi.py vs. openapi_async.py.
• Tests continue to pass for both sync and async workflows.