rest-api-design
aj-geddes/useful-ai-prompts
Design RESTful APIs following best practices for resource modeling, HTTP methods, status codes, and versioning.
What is rest-api-design?
Guidance for designing intuitive, consistent RESTful APIs with proper resource naming, HTTP semantics, status codes, versioning, and documentation. Use when creating new APIs, designing endpoints, or refactoring existing API architecture.
- Use nouns and plural names for resource endpoints with consistent naming conventions
- Apply correct HTTP methods (GET, POST, PUT, DELETE) for resource operations
- Return appropriate HTTP status codes and clear error messages
- Implement pagination, filtering, and sorting for collections
- Version APIs and maintain backward compatibility
- Document APIs with OpenAPI specifications
How to install rest-api-design
npx skills add https://github.com/aj-geddes/useful-ai-prompts --skill rest-api-designHow to use rest-api-design
- 1.Review the resource naming guide to establish consistent endpoint patterns using nouns and plural forms
- 2.Define HTTP methods for each resource operation (GET for retrieval, POST for creation, etc.)
- 3.Select appropriate HTTP status codes for success and error responses
- 4.Plan API versioning strategy before implementation
- 5.Structure request and response formats using the provided examples
- 6.Add pagination, filtering, and sorting for collection endpoints
- 7.Document your API using OpenAPI specification format
- 8.Implement authentication, rate limiting, and HTTPS security
Use cases
- Designing new RESTful API endpoints from scratch
- Refactoring existing APIs to follow resource-oriented architecture
- Creating consistent request/response formats across multiple endpoints
- Implementing API versioning strategies for evolving services
- Writing OpenAPI documentation for API specifications
- Backend developers building APIs
- API architects designing service contracts
- Full-stack developers creating new services
- Teams standardizing API design across projects
rest-api-design FAQ
Use plural names for collections (e.g., /api/users, /api/products). This maintains consistency and clarity about what the endpoint represents.
Use appropriate 4xx codes for client errors (400 Bad Request, 401 Unauthorized, 404 Not Found) and 5xx for server errors (500 Internal Server Error). Never return 200 for errors.
Limit nesting to a maximum of 2 levels (e.g., /api/users/123/orders). Deeper nesting becomes difficult to maintain and understand.
Plan versioning before launch. Use URL versioning (/api/v1/, /api/v2/) or header-based versioning. Always maintain backward compatibility or provide a clear deprecation path.
Use OpenAPI specification to document all endpoints, request/response formats, status codes, authentication requirements, and provide example requests and responses.
Full instructions (SKILL.md)
Source of truth, from aj-geddes/useful-ai-prompts.
name: rest-api-design description: > Design RESTful APIs following best practices for resource modeling, HTTP methods, status codes, versioning, and documentation. Use when creating new APIs, designing endpoints, or improving existing API architecture.
REST API Design
Table of Contents
Overview
Design REST APIs that are intuitive, consistent, and follow industry best practices for resource-oriented architecture.
When to Use
- Designing new RESTful APIs
- Creating endpoint structures
- Defining request/response formats
- Implementing API versioning
- Documenting API specifications
- Refactoring existing APIs
Quick Start
Minimal working example:
✅ Good Resource Names (Nouns, Plural)
GET /api/users
GET /api/users/123
GET /api/users/123/orders
POST /api/products
DELETE /api/products/456
❌ Bad Resource Names (Verbs, Inconsistent)
GET /api/getUsers
POST /api/createProduct
GET /api/user/123 (inconsistent singular/plural)
Reference Guides
Detailed implementations in the references/ directory:
| Guide | Contents |
|---|---|
| Resource Naming | Resource Naming, HTTP Methods & Operations |
| Request Examples | Request Examples |
| Query Parameters | Query Parameters |
| Response Formats | Response Formats |
| HTTP Status Codes | HTTP Status Codes, API Versioning, Authentication & Security, Rate Limiting Headers |
| OpenAPI Documentation | OpenAPI Documentation |
| Complete Example: Express.js | const express = require("express"); |
Best Practices
✅ DO
- Use nouns for resources, not verbs
- Use plural names for collections
- Be consistent with naming conventions
- Return appropriate HTTP status codes
- Include pagination for collections
- Provide filtering and sorting options
- Version your API
- Document thoroughly with OpenAPI
- Use HTTPS
- Implement rate limiting
- Provide clear error messages
- Use ISO 8601 for dates
❌ DON'T
- Use verbs in endpoint names
- Return 200 for errors
- Expose internal IDs unnecessarily
- Over-nest resources (max 2 levels)
- Use inconsistent naming
- Forget authentication
- Return sensitive data
- Break backward compatibility without versioning
Related skills
More from aj-geddes/useful-ai-prompts and the wider catalog.

technical-specification
>

user-guide-creation
>

user-story-writing
>

wireframe-prototyping
>

flutter-ui-ux
|

terragrunt-generator
Generate/create/scaffold Terragrunt HCL files — root.hcl, terragrunt.hcl, child modules, stacks, multi-env layouts.