PluginBench
Skill
Pass
Audit score 90

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-design
Claude Code
Cursor
Windsurf
Cline

How to use rest-api-design

  1. 1.Review the resource naming guide to establish consistent endpoint patterns using nouns and plural forms
  2. 2.Define HTTP methods for each resource operation (GET for retrieval, POST for creation, etc.)
  3. 3.Select appropriate HTTP status codes for success and error responses
  4. 4.Plan API versioning strategy before implementation
  5. 5.Structure request and response formats using the provided examples
  6. 6.Add pagination, filtering, and sorting for collection endpoints
  7. 7.Document your API using OpenAPI specification format
  8. 8.Implement authentication, rate limiting, and HTTPS security

Use cases

Good for
  • 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
Who it's for
  • 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

Should I use singular or plural names for resources?

Use plural names for collections (e.g., /api/users, /api/products). This maintains consistency and clarity about what the endpoint represents.

What HTTP status code should I return for errors?

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.

How deep should I nest resources in my endpoints?

Limit nesting to a maximum of 2 levels (e.g., /api/users/123/orders). Deeper nesting becomes difficult to maintain and understand.

When should I version my API?

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.

What should I include in API documentation?

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:

GuideContents
Resource NamingResource Naming, HTTP Methods & Operations
Request ExamplesRequest Examples
Query ParametersQuery Parameters
Response FormatsResponse Formats
HTTP Status CodesHTTP Status Codes, API Versioning, Authentication & Security, Rate Limiting Headers
OpenAPI DocumentationOpenAPI Documentation
Complete Example: Express.jsconst 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