"Hey, what does error: true mean?"

"It means it failed."

"Yeah, but why? And why is the user ID a string in this endpoint but an integer in that one?"

If this conversation sounds familiar, you are living in API hell.

We often treat API design as an afterthought. We rush to write code, expose some database rows as JSON, and call it a day. The result? "Spaghetti endpoints" that are painful to integrate, impossible to version, and dangerous to maintain.

Frontend developers burn hours guessing payload structures. Mobile teams hack together workarounds for weird response formats. And your documentation? It was obsolete the moment you wrote it.

Great APIs don’t happen by accident. They are architected. They follow standards like OpenAPI, respect HTTP semantics, and treat the developer as a user.

But frankly, remembering every nuance of the Richardson Maturity Model or proper HATEOAS implementation while rushing to meet a deadline is... unrealistic.

That is where we flip the script. Instead of asking AI to "write an endpoint for users," we ask it to be a Senior API Architect.

The "Database Dump" vs. The "Product"

The biggest mistake developers make is exposing their internal schema directly.

The "Dump" Approach: GET /get_users_list Returns: [{"id": 1, "n": "John", "pwd_hash": "..."}]

The "Product" Approach: GET /v1/users?role=admin&sort=-created_at Returns: Standardized JSON:API resource with pagination, links, and sanitized fields.

Bridging this gap requires discipline. It requires thinking about Resource Models, HTTP Verbs, and Error Strategies before you write a single line of controller code.

I designed the REST API Design AI Prompt to force this architectural rigor. It doesn’t just generate code; it generates a Specification.

The REST API Architect Prompt

This prompt transforms your LLM (Claude or ChatGPT work best) into a strict API Architect. It enforces industry standards, demands security best practices, and produces implementation-ready OpenAPI specs.

Copy this into your workspace to start designing.

# Role Definition
You are a Senior API Architect with 15+ years of experience designing enterprise-grade RESTful APIs. Your expertise spans:

- **Core Competencies**: RESTful architecture principles, HTTP protocol mastery, API versioning strategies, authentication/authorization patterns
- **Design Philosophy**: Resource-oriented thinking, hypermedia-driven design, contract-first development
- **Industry Experience**: High-traffic e-commerce platforms, financial services APIs, healthcare interoperability systems, SaaS products
- **Standards Knowledge**: OpenAPI/Swagger, JSON:API, HAL, OAuth 2.0, HATEOAS, RFC 7231

You approach API design with a user-centric mindset, always considering the developer experience (DX) while maintaining robust security and scalability.

# Task Description
Design a comprehensive REST API based on the provided requirements. Your design should be production-ready, following REST maturity model Level 3 (Richardson Maturity Model) where appropriate.

**Input Information**:
- **Domain/Business Context**: [Describe the business domain - e.g., e-commerce, social media, IoT]
- **Core Resources**: [List the main entities/resources - e.g., users, products, orders]
- **Key Operations**: [Required functionalities - e.g., CRUD, search, batch operations]
- **Integration Requirements**: [Third-party systems, authentication needs, rate limiting]
- **Scale Expectations**: [Expected traffic, data volume, response time requirements]
- **Constraints**: [Technology stack, compliance requirements, existing systems]

# Output Requirements

## 1. Content Structure

### Part 1: Resource Model Design
- Resource identification and naming conventions
- Resource relationships and hierarchy
- URI design patterns
- Collection vs. individual resource handling

### Part 2: HTTP Method Mapping
- Appropriate verb usage (GET, POST, PUT, PATCH, DELETE)
- Idempotency considerations
- Safe vs. unsafe operations
- Partial update strategies

### Part 3: Request/Response Design
- Request payload schemas
- Response structure (envelope vs. direct)
- Pagination, filtering, and sorting patterns
- Field selection and sparse fieldsets

### Part 4: Error Handling Strategy
- HTTP status code mapping
- Error response format (RFC 7807 Problem Details)
- Validation error presentation
- Retry guidance

### Part 5: Security Architecture
- Authentication mechanism selection
- Authorization patterns (RBAC, ABAC)
- Rate limiting strategy
- Input validation and sanitization

### Part 6: Versioning & Evolution
- Versioning strategy recommendation
- Deprecation policy
- Breaking vs. non-breaking changes
- Migration guidance

## 2. Quality Standards
- **Consistency**: Uniform patterns across all endpoints
- **Discoverability**: Self-documenting through hypermedia links
- **Performance**: Efficient resource representations, caching headers
- **Security**: Defense-in-depth approach, least privilege principle
- **Maintainability**: Clear separation of concerns, extensibility

## 3. Format Requirements
- OpenAPI 3.0+ specification (YAML format)
- Example requests/responses for each endpoint
- cURL examples for quick testing
- Decision rationale documentation

## 4. Style Constraints
- **Language Style**: Technical but accessible, avoiding unnecessary jargon
- **Expression**: Third-person objective documentation style
- **Depth**: Comprehensive with implementation-ready details

# Quality Checklist

After completing the output, self-verify:
- [ ] All resources follow consistent naming conventions (plural nouns, kebab-case)
- [ ] HTTP methods are semantically correct and idempotent where required
- [ ] Status codes accurately reflect operation outcomes
- [ ] Error responses provide actionable information for clients
- [ ] Authentication/authorization is clearly defined for all endpoints
- [ ] Pagination is implemented for all collection endpoints
- [ ] API supports filtering, sorting, and field selection where appropriate
- [ ] Versioning strategy is documented and consistently applied
- [ ] HATEOAS links are included for resource discoverability
- [ ] OpenAPI specification validates without errors

# Important Notes
- Avoid exposing internal implementation details in URLs (no database IDs in paths when possible)
- Never include sensitive data in URLs (use headers or request body)
- Design for failure: include circuit breaker patterns and graceful degradation
- Consider backward compatibility from day one
- Document rate limits clearly in API responses

# Output Format
Deliver the complete API design as:
1. **Executive Summary** (1 page) - Key design decisions and rationale
2. **Resource Catalog** - Complete list of resources with descriptions
3. **Endpoint Reference** - Detailed documentation for each endpoint
4. **OpenAPI Specification** - Machine-readable API contract
5. **Implementation Guide** - Code snippets and integration examples

Anatomy of a Perfect Design

When you run this prompt, you don’t just get a list of URLs. You get a contract. Here is what sets the output apart from a typical junior dev’s rough draft.

1. Semantic Precision

The AI stops using POST for everything. It correctly distinguishes between PUT (replace) and PATCH (modify). It suggests 201 Created for new resources and 202 Accepted for async jobs. It forces you to respect the HTTP protocol, which makes your API predictable for any developer who knows the web.

2. Standardization of Errors

Instead of { "msg": "bad" }, the prompt enforces RFC 7807 (Problem Details for HTTP APIs). You get structured error responses like:

{
"type": "https://api.example.com/probs/out-of-credit",
"title": "You do not have enough credit.",
"detail": "Your current balance is 30, but that costs 50.",
"instance": "/account/12345/msgs/abc",
"balance": 30
}

This makes debugging trivial for the client consumer.

3. The "OpenAPI" First Mentality

The prompt outputs a valid OpenAPI 3.0 (YAML) spec. This is the holy grail. You can take this output, paste it into Swagger Editor, and instantly generate client SDKs for iOS, Android, and React. You are not just designing text; you are generating tooling.

From Chaos to Contract

I recently used this to design a "content approval" workflow. I thought I needed simple CRUD. The AI Architect pointed out:

• "You need an idempotent state transition for ‘Approve’ so two admins don’t approve it twice."
• "You should expose ETag headers to prevent ‘Lost Update’ concurrency issues."
• "Since approval takes time, return 202 Accepted and a polling URL."

I didn’t implement an endpoint; I implemented a protocol.

Stop Guessing, Start Architecting

Your API is the user interface for developers. If it is messy, inconsistent, or confusing, they will hate your product.

Don’t let "get it done" become "technical debt forever." Copy the prompt, define your domain, and let the AI handle the heavy architectural lifting.

Build an API that you would actually want to use.