API Design Patterns

Inspect the owning package and existing implementation first. Reuse established project types, helpers, errors, lifecycle behavior, and test utilities. The patterns below are options, not an implementation checklist. Introduce one only when the current task requires it.

Project-specific rules

• Preserve existing API contracts during internal migrations.
• Apply versioning, pagination, error-format, status-code, and idempotency guidance only when the task explicitly changes the public API.
• Do not turn REST preferences into unrelated migration scope.

Use the following patterns only when the task designs or explicitly changes the public API. For internal work, preserve the current routes, payloads, errors, status codes, pagination, and idempotency behavior.

Additional References