Design frontend-backend contracts for authorization workflows

Interview framing: Good frontend-backend contracts reduce ambiguity. For authorization workflows, they also prevent dangerous UI assumptions.

Contract design:

1. Typed DTOs:

• Define request/response types for policies, subjects, resources, actions, simulation results, and audit entries.
• Prefer explicit enums for status/effect over loose strings.
• Include server-generated IDs, versions, timestamps, and actor metadata.

2. Error model:

• Return structured errors with code, message, field errors, and retryability.
• Distinguish 401, 403, 404, validation errors, conflicts, and server failures.
• Avoid leaking sensitive policy details in errors.

3. Concurrency:

• Use policy versions or ETags to avoid overwriting someone else’s change.
• Show conflict resolution UI when a draft is stale.

4. Publishing flow:

• Separate draft save from publish.
• Return validation warnings and policy impact summaries before activation.
• Audit publish events with actor, diff, and timestamp.

5. Optimistic updates:

• Safe for low-risk UI preferences.
• Be cautious for policy changes; prefer confirmed writes for security-sensitive state.

6. Versioning:

• Keep contracts backwards-compatible across rolling deployments.
• Add fields instead of changing meaning.
• Use generated clients or schema validation when available.

Good closing: "For authorization products, the frontend can guide the workflow, but the backend contract must be explicit about decisions, errors, versions, and auditability."