review-api-design

name	review-api-design
description	Reviews REST API designs during the planning phase against security, resilience, design, and operational best practices. Use when vetting an API design, reviewing an OpenAPI spec, critiquing endpoint structure, or evaluating API contracts before implementation. Triggers on "review my API", "API design review", "REST review", or "vet this API". Activates naturally during plan mode when API endpoints, contracts, or service boundaries are being designed. Make sure to use this skill whenever an API design, endpoint list, or OpenAPI specification is presented for feedback.
user-invocable	true
argument-hint	[paste or describe your API design]
license	CC-BY-4.0
effort	high
metadata	{"author":"Philip A Senger","version":"1.0.0","source":"https://github.com/psenger/Best-Practices-For-Rest-API"}

REST API Design Review

Review the following API design: $ARGUMENTS

If no design was provided above, ask for an API design to review (OpenAPI spec, endpoint list, or verbal description).

This skill vets API designs before implementation — during the planning phase. It reviews contracts, endpoint structures, and architectural decisions against proven best practices. Reviews are constructive but thorough — challenging the design, flagging gaps, and surfacing trade-offs.

When This Skill Activates

• An OpenAPI/Swagger specification (YAML or JSON)
• A list of endpoints with descriptions
• A verbal description of an API being planned
• A diagram or document describing API architecture
• Questions about how to design specific API aspects

Workflow

Step 1: Understand the Context

Before reviewing, gather context. Ask about anything not already clear:

1. Domain — What business domain does this API serve?
2. Consumers — Who will call this API? (frontend, mobile, third-party, internal services)
3. Scale — Expected traffic volume and growth trajectory
4. Auth requirements — What authentication/authorization is planned?
5. Deployment — Where will this run? (cloud provider, on-prem, serverless)
6. Existing systems — Does this integrate with legacy systems or other APIs?
7. Team — How experienced is the team with REST API development?

Do not ask all of these mechanically. Read what was already provided and only ask what's missing and relevant. If given an OpenAPI spec, extract most of this from the spec itself.

When the input is a vague verbal description (no concrete endpoints, no spec, no endpoint list — just "I'm building an API for X"), asking clarifying questions is mandatory before producing any review. A vague description does not contain enough information to assign severity levels or make specific recommendations. Ask 3-5 targeted questions, wait for answers, then proceed to Step 2. Do not produce a full review from a verbal description alone.

Step 2: Load Relevant References

Based on the design presented, read the reference files that are most relevant. Not all files need loading for every review.

Always load:

• references/design-principles.md — naming, versioning, CRUD, idempotency, health checks, tracing, parameters
• references/payloads-errors.md — response structure, pagination, error format, identifiers

Load based on context:

• references/security-auth.md — if the API handles auth, identity, tokens, or trust boundaries
• references/security-defense.md — if the API is public-facing, handles user input, or needs hardening (CSRF, CORS, enumeration, information disclosure)
• references/design-extensibility.md — if the design involves extensibility, metadata fields, backwards compatibility strategy, or arity decisions
• references/resilience.md — if the API calls downstream services or needs high availability
• references/api-gateways.md — if there are multiple services or gateway architecture questions
• references/api-communication-patterns.md — if weighing REST vs GraphQL vs WebSockets vs SSE, or the design shows signs that a different pattern might fit better
• references/human-aspect.md — if adoption, documentation, or developer experience is a concern
• references/pragmatism.md — if there are technology choice or build-vs-buy decisions

Step 3: Conduct the Review

Systematically evaluate the design against each relevant domain. For each finding:

• Identify what's good (reinforce good decisions)
• Identify what's missing or could be improved
• Explain why it matters, not just what to change
• Assign a severity level

Severity levels:

Level	Meaning
Critical	Will cause production incidents, security vulnerabilities, or major integration pain. Must fix before building.
Warning	Likely to cause problems at scale or create tech debt. Should fix before building.
Suggestion	Would improve the design but not blocking. Consider for this iteration or next.
Good	Something done well worth reinforcing.

Step 4: Produce the Review Document

Structure output as follows:

API Design Review: {API Name}

Review date: {date} Input: {what was provided — spec, endpoint list, description} Context: {1-2 sentence summary of the API's purpose and audience}

Summary of Findings

#	Domain	Finding	Severity
1	Design	...	Critical
2	Security	...	Warning

Detailed Findings

For each finding:

• What: The specific issue or observation
• Why it matters: The consequence of not addressing it
• Recommendation: What to do about it, citing relevant standards or guides from references/sources.md so the user has a concrete next step (e.g., "See OWASP CSRF Prevention Cheat Sheet in sources.md")

Group findings by domain (Design Principles, Security, Resilience, etc.).

What's Missing?

Flag areas the design didn't address. Common gaps:

• No error response format defined
• No versioning strategy
• No pagination approach for list endpoints
• No authentication/authorization model
• No rate limiting strategy
• No health check endpoints
• No idempotency strategy for writes
• No caching strategy
• No correlation ID / tracing strategy

Readiness Assessment

• Ready to build — No critical or warning findings.
• Ready with changes — Has warnings. List the top 3 priorities.
• Needs more design work — Has critical findings. Summarize what must happen first.

Example Review Excerpt

Given input: POST /users, GET /users/{id}, DELETE /users/{id}, GET /orders

#	Domain	Finding	Severity
1	Design	No versioning strategy — endpoints lack version prefix	Warning
2	Payloads	No error format defined — consider RFC 9457 Problem Details	Warning
3	Security	No auth model specified for a user-facing API	Critical
4	Design	DELETE /users/{id} is idempotent by nature	Good

Finding 1 — No versioning strategy

• What: Endpoints have no version prefix (/users instead of /v1/users).
• Why it matters: Without versioning, breaking changes will either break consumers or force awkward workarounds. Adding versioning retroactively is painful.
• Recommendation: Add URL-based versioning with major version only: /v1/users, /v1/orders. Plan Sunset headers (RFC 8594) for future deprecation.

Behavioral Guidelines

1. Planning, not coding. Review designs, not code. Only generate implementation examples if specifically asked.
2. Pragmatic, not dogmatic. Best practices are guidelines. Flag deviations as conscious decisions, not oversights.
3. Context-sensitive. Scale rigor to the context — internal microservice vs public API for thousands of developers.
4. Constructive tone. Lead with what's good before what needs work.
5. Ask before assuming. If something looks wrong but might be intentional, ask.
6. Teach the why. Explain reasoning behind each finding.
7. Prioritize. Make it clear what's critical vs. nice-to-have.