How the TencentDB Agent Memory SDK Transport Interface Supports Dual GET/POST via the `requestGet` Abstraction

The SDK's Transport interface makes get optional and provides a requestGet helper that automatically falls back to POST when GET is unavailable, enabling flexible HTTP method selection without breaking client code.

The TencentDB-Agent-Memory TypeScript SDK abstracts HTTP communication through a clean Transport interface. This design lets memory-related clients work with both standard HTTP transports and custom implementations—whether they support GET, POST, or both—without requiring conditional logic in every API call.

The Transport Interface Design

In src/client.ts (lines 24–28), the SDK defines the core Transport contract:

export interface Transport {
  /** POST is mandatory. */
  post<T>(path: string, body?: Record<string, unknown>): Promise<T>;

  /** GET is optional – older or custom transports may only implement POST. */
  get?<T>(path: string, query?: Record<string, unknown>): Promise<T>;
}

This interface makes post required while keeping get optional. The SDK maintains backward compatibility with existing transports that only implement POST, while still enabling full GET support for modern implementations.

How requestGet Enables Dual GET/POST Support

The requestGet abstraction in src/v3/memory-prompt-client.ts (lines 68–70) makes the HTTP method choice transparent to callers:

private requestGet<T>(path: string, query: Record<string, unknown>): Promise<T> {
  // Prefer GET if the transport provides it; otherwise fall back to POST.
  return this.http.get ? this.http.get<T>(path, query) : this.http.post<T>(path, query);
}

Runtime detection determines which method to use:

• If this.http.get exists → sends HTTP GET with query parameters
• If this.http.get is absent → sends POST with the query object as the request body

This pattern appears consistently across the SDK. MemoryPromptClient.get, list, listSettings, and similar methods all invoke requestGet, shielding calling code from HTTP-level decisions.

Key Implementation Mechanisms

Four design decisions enable this flexible GET/POST support:

1. Transport injection — Clients accept either a concrete Transport implementation or a MemoryClientConfig object that the SDK converts to a default V3HttpTransport

2. Optional method signature — The get? syntax in the interface allows partial implementations without type errors

3. Runtime capability check — requestGet evaluates this.http.get at call-time, not build-time

4. Uniform client API — All public methods delegate to requestGet, ensuring consistent behavior regardless of transport capabilities

Practical Examples

Standard Usage with Full GET Support

The built-in V3HttpTransport (in src/v3/http.ts) implements both methods:

import { MemoryPromptClient } from '@tencentcloud/sdk-memory-core';

const client = new MemoryPromptClient({
  endpoint: 'https://memory.tencentyun.com',
  apiKey: 'YOUR_API_KEY',
  serviceId: 'svc-123',
});

await client.get('prompt-id');   // → uses HTTP GET internally

Custom Transport with POST-Only Fallback

Test mocks or legacy integrations can omit get:

import { Transport } from '@tencentcloud/sdk-memory-core';

const mockTransport: Transport = {
  async post(path, body) {
    // handle request as POST (e.g., record for tests)
    return Promise.resolve({ /* mock response */ });
  },
  // `get` is omitted → requestGet will call `post` instead
};

const client = new MemoryPromptClient(mockTransport);
await client.get('prompt-id');   // → internally calls mockTransport.post

Where This Pattern Appears in the Source

File	Role	Implementation
src/client.ts	Defines Transport interface with optional get	View source
src/v3/http.ts	V3HttpTransport implements both post and get	View source
src/v3/memory-prompt-client.ts	requestGet helper with runtime method selection	View source
src/v3/skill-client.ts	Same GET/POST pattern for skill endpoints	View source
src/v3/metadata-client.ts	GET/POST fallback for metadata services	View source

Summary

• The Transport interface makes GET optional while requiring POST, maximizing compatibility
• The requestGet helper automatically selects GET when available, POST otherwise
• Runtime detection (not build-time) determines the HTTP method, enabling dynamic transport injection
• Multiple client classes (MemoryPromptClient, SkillClient, MetadataClient) reuse this pattern consistently
• Developers can inject custom transports for testing or legacy integration without breaking SDK functionality

Frequently Asked Questions

What happens if my transport implements both get and post?

The SDK always prefers GET for read operations. When requestGet detects this.http.get is defined, it calls that method with the query parameters as URL-encoded arguments. The POST method remains available for explicit write operations.

Why make get optional instead of required?

According to the TencentDB-Agent-Memory source code, this preserves backward compatibility with transports created before GET support was added. It also enables lightweight test mocks that only need to verify POST payloads without implementing full URL construction logic.

Can I force POST even when GET is available?

The public API doesn't expose this option—requestGet always prefers GET when present. To force POST, inject a transport wrapper that exposes post normally but omits or throws from get, triggering the fallback behavior.

Is this pattern used outside MemoryPromptClient?

Yes. The same requestGet implementation appears in SkillClient (src/v3/skill-client.ts) and MetadataClient (src/v3/metadata-client.ts), confirming this as a SDK-wide convention for transport abstraction rather than a one-off implementation detail.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}