API Development & Design — Quick Reference
Use this skill to design, implement, and document production-grade APIs (REST, GraphQL, gRPC, and tRPC). Apply it for contract design (OpenAPI), versioning/deprecation, authentication/authorization, rate limiting, pagination, error models, and developer documentation.
Modern best practices (Jan 2026): HTTP semantics and cacheability (RFC 9110), Problem Details error model (RFC 9457), OpenAPI 3.1+, contract-first + breaking-change detection, strong AuthN/Z boundaries, explicit versioning/deprecation, and operable-by-default APIs (idempotency, rate limits, observability, trace context).
Default Execution Checklist
- Choose an API style based on constraints (public vs internal, performance, client query flexibility).
- Define the contract first (OpenAPI or GraphQL schema; protobuf for gRPC).
- Define the error model (RFC 9457 + stable error codes + trace IDs).
- Define AuthN/AuthZ boundaries (scopes/roles/tenancy) and threat model.
- Define pagination/filter/sort for all list endpoints.
- Define rate limits/quotas, idempotency strategy (esp. POST), and retries/backoff guidance.
- Define observability (W3C Trace Context, request IDs, metrics, logs) and SLOs.
- Add contract tests + breaking-change checks in CI.
- Publish docs with examples + migration/deprecation policy.
Quick Reference
| Task |
Pattern/Tool |
Key Elements |
When to Use |
| Design REST API |
RESTful Design |
Nouns (not verbs), HTTP methods, proper status codes |
Resource-based APIs, CRUD operations |
| Version API |
URL Versioning |
/api/v1/resource, /api/v2/resource |
Breaking changes, client migration |
| Paginate results |
Cursor-Based |
cursor=eyJpZCI6MTIzfQ&limit=20 |
Real-time data, large collections |
| Handle errors |
RFC 9457 Problem Details |
type, title, status, detail, errors[] |
Consistent error responses |
| Authenticate |
JWT Bearer |
Authorization: Bearer <token> |
Stateless auth, microservices |
| Rate limit |
Token Bucket |
X-RateLimit-* headers, 429 responses |
Prevent abuse, fair usage |
| Document API |
OpenAPI 3.1 |
Swagger UI, Redoc, code samples |
Interactive docs, client SDKs |
| Flexible queries |
GraphQL |
Schema-first, resolvers, DataLoader |
Client-driven data fetching |
| High-performance |
gRPC + Protobuf |
Binary protocol, streaming |
Internal microservices |
| TypeScript-first |
tRPC |
End-to-end type safety, no codegen |
Monorepos, internal tools |
| AI agent APIs |
REST + MCP |
Agent experience, machine-readable |
LLM/agent consumption |
Decision Tree: Choosing API Style
User needs: [API Type]
├─ Public API for third parties?
│ └─ REST with OpenAPI docs (broad compatibility)
│
├─ Internal microservices?
│ ├─ High throughput required? → **gRPC** (binary, fast)
│ └─ Simple CRUD? → **REST** (easy to debug)
│
├─ TypeScript monorepo (frontend + backend)?
│ └─ **tRPC** (end-to-end type safety, no codegen)
│
├─ Client needs flexible queries?
│ ├─ Real-time updates? → **GraphQL Subscriptions** or **WebSockets**
│ └─ Complex data fetching? → **GraphQL** (avoid over-fetching)
│
├─ Mobile/web clients?
│ ├─ Many entity types? → **GraphQL** (single endpoint)
│ └─ Simple resources? → **REST** (cacheable)
│
├─ AI agents consuming API?
│ └─ REST + **MCP** wrapper (agent experience)
│
└─ Streaming or bidirectional?
└─ **gRPC** (HTTP/2 streaming) or **WebSockets**
Navigation: Core API Patterns
RESTful API Design
Resource: references/restful-design-patterns.md
- Resource-based URLs with proper HTTP methods (GET, POST, PUT, PATCH, DELETE)
- HTTP status code semantics (200, 201, 404, 422, 500)
- Idempotency guarantees (GET, PUT, DELETE)
- Stateless design principles
- URL structure best practices (collection vs resource endpoints)
- Nested resources and action endpoints
Pagination, Filtering & Sorting
Resource: references/pagination-filtering.md
- Offset-based pagination (simple, static datasets)
- Cursor-based pagination (real-time feeds, recommended)
- Page-based pagination (UI with page numbers)
- Query parameter filtering with operators (
_gt, _contains, _in)
- Multi-field sorting with direction (
-created_at)
- Performance optimization with indexes
Error Handling
Resource: references/error-handling-patterns.md
- RFC 9457 Problem Details standard
- HTTP status code reference (4xx client errors, 5xx server errors)
- Field-level validation errors
- Trace IDs for debugging
- Consistent error format across endpoints
- Security-safe error messages (no stack traces in production)
Authentication & Authorization
Resource: references/authentication-patterns.md
- JWT (JSON Web Tokens) with refresh token rotation
- OAuth2 Authorization Code Flow for third-party auth
- API Key authentication for server-to-server
- RBAC (Role-Based Access Control)
- ABAC (Attribute-Based Access Control)
- Resource-based authorization (user-owned resources)
Rate Limiting & Throttling
Resource: references/rate-limiting-patterns.md
- Token Bucket algorithm (recommended, allows bursts)
- Fixed Window vs Sliding Window
- Rate limit headers (
X-RateLimit-*)
- Tiered rate limits (free, paid, enterprise)
- Redis-based distributed rate limiting
- Per-user, per-endpoint, and per-API-key strategies
Navigation: Extended Resources
API Design & Best Practices
- api-design-best-practices.md - Comprehensive API design principles
- versioning-strategies.md - URL, header, and query parameter versioning
- api-security-checklist.md - OWASP API Security Top 10
GraphQL & gRPC
- graphql-patterns.md - Schema design, resolvers, N+1 queries, DataLoader
- gRPC patterns - See software-backend for Protocol Buffers and service definitions
tRPC (TypeScript-First)
- trpc-patterns.md - End-to-end type safety, procedures, React Query integration
- When to use tRPC vs GraphQL vs REST
- Auth middleware patterns
- Server-side rendering with Next.js
OpenAPI & Documentation
- openapi-guide.md - OpenAPI 3.1 specifications, Swagger UI, Redoc
- Templates: assets/openapi-template.yaml - Complete OpenAPI spec example
Optional: AI/Automation (LLM/Agent APIs)
- llm-agent-api-contracts.md - Streaming, long-running jobs, safety guardrails, observability
Navigation: Templates
Production-ready, copy-paste API implementations with authentication, database, validation, and docs.
Framework-Specific Templates
FastAPI (Python): assets/fastapi/fastapi-complete-api.md
- Async/await, Pydantic v2, JWT auth, SQLAlchemy 2.0, pagination, OpenAPI docs
Express.js (Node/TypeScript): assets/express-nodejs/express-complete-api.md
- TypeScript, Zod validation, Prisma ORM, JWT refresh tokens, rate limiting
Django REST Framework: assets/django-rest/django-rest-complete-api.md
- ViewSets, serializers, Simple JWT, permissions, DRF filtering/pagination
Spring Boot (Java): assets/spring-boot/spring-boot-complete-api.md
- Spring Security JWT, Spring Data JPA, Bean Validation, Springdoc OpenAPI
Cross-Platform Patterns
- api-patterns-universal.md - Universal patterns for all frameworks
- Authentication strategies, pagination, caching, versioning, validation
- template-api-governance.md - API governance, deprecation, multi-tenancy
- Deprecation policy (90-day timeline), backward compatibility rules, error model templates
- template-api-design-review-checklist.md - Production API review checklist (security, reliability, operability)
- template-api-error-model.md - RFC 9457 Problem Details + stable error code registry
Do / Avoid
GOOD: Do
- Version APIs from day one
- Document deprecation policy before first deprecation
- Treat breaking changes as a major version (and keep minor changes backward compatible)
- Include trace IDs in all error responses
- Return appropriate HTTP status codes
- Implement rate limiting with clear headers
- Use RFC 9457 Problem Details for errors
BAD: Avoid
- Removing fields without deprecation period
- Changing field types in existing versions
- Using verbs in resource names (nouns only)
- Returning 500 for client errors
- Breaking changes without major version bump
- Mixing tenant data without explicit isolation
- Action endpoints everywhere (/doSomething)
Anti-Patterns
| Anti-Pattern |
Problem |
Fix |
| Instant deprecation |
Breaks clients |
90-day minimum sunset period |
| Action endpoints |
Inconsistent API |
Use resources + HTTP verbs |
| Version in body |
Hard to route, debug |
Version in URL or header |
| Generic errors |
Poor DX |
Specific error codes + messages |
| No rate limit headers |
Clients can't back off |
Include X-RateLimit-* |
| Tenant ID in URL only |
Forgery risk |
Validate against auth token |
| Leaky abstractions |
Tight coupling |
Design stable contracts |
Optional: AI/Automation
Note: AI tools assist but contracts need human review.
- OpenAPI linting — Spectral, Redocly in CI/CD
- Breaking change detection — oasdiff automated checks
- SDK generation — From OpenAPI spec on changes
- Contract testing — Pact, Dredd automation
Bounded Claims
- AI-generated OpenAPI specs require human review
- Automated deprecation detection needs manual confirmation
- SDK generation requires type verification
External Resources
See data/sources.json for:
- Official REST, GraphQL, gRPC documentation
- OpenAPI/Swagger tools and validators
- API design style guides (Google, Microsoft, Stripe)
- Security standards (OWASP API Security Top 10)
- Testing tools (Postman, Insomnia, Paw)
Related Skills
This skill works best when combined with other specialized skills:
Backend Development
- software-backend - Production backend patterns (Node.js, Python, Java frameworks)
- Use when implementing API server infrastructure
- Covers database integration, middleware, error handling
Security & Authentication
- software-security-appsec - Application security patterns
- Critical for securing API endpoints
- Covers OWASP vulnerabilities, authentication flows, input validation
Database & Data Layer
- data-sql-optimization - SQL optimization and database patterns
- Essential for API performance (query optimization, indexing)
- Use when APIs interact with relational databases
Testing & Quality
- qa-testing-strategy - Test strategy and automation
- Contract testing for API specifications
- Integration testing for API endpoints
DevOps & Deployment
- ops-devops-platform - Platform engineering and deployment
- API gateway configuration
- CI/CD pipelines for API deployments
Documentation
- docs-codebase - Technical documentation standards
- API reference documentation structure
- Complements OpenAPI auto-generated docs
Architecture
Performance & Observability
- qa-observability - Performance optimization and monitoring
- API latency monitoring, distributed tracing
- Performance budgets for API endpoints
Usage Notes
For the agent:
- Apply RESTful principles by default unless user requests GraphQL/gRPC
- Always include pagination for list endpoints
- Use RFC 9457 format for error responses
- Include authentication in all templates (JWT or API keys)
- Reference framework-specific templates for complete implementations
- Link to relevant resources for deep-dive guidance
Success Criteria: APIs are discoverable, consistent, well-documented, secure, and follow HTTP/GraphQL semantics correctly.
Time-Sensitive Recommendations
If a user asks for "best" tools/frameworks, "latest" standards, or whether something is still relevant in 2026, do a quick web search using whatever browsing/search tool is available in the current environment. If web access is unavailable, answer from stable principles, state assumptions (traffic, latency, team skills, ecosystem), and avoid overstating currency.
1---2name: dev-api-design3description: Production-grade API design patterns for REST, GraphQL, gRPC, and tRPC. Covers API architecture, OpenAPI/Swagger specs, versioning/deprecation, authentication/authorization, rate limiting, pagination, error models, contract testing, and developer documentation.4---5
6# API Development & Design — Quick Reference
7
8Use this skill to design, implement, and document production-grade APIs (REST, GraphQL, gRPC, and tRPC). Apply it for contract design (OpenAPI), versioning/deprecation, authentication/authorization, rate limiting, pagination, error models, and developer documentation.
9
10**Modern best practices (Jan 2026)**: HTTP semantics and cacheability (RFC 9110), Problem Details error model (RFC 9457), OpenAPI 3.1+, contract-first + breaking-change detection, strong AuthN/Z boundaries, explicit versioning/deprecation, and operable-by-default APIs (idempotency, rate limits, observability, trace context).
11
12---
13
14## Default Execution Checklist
15
16- Choose an API style based on constraints (public vs internal, performance, client query flexibility).
17- Define the contract first (OpenAPI or GraphQL schema; protobuf for gRPC).
18- Define the error model (RFC 9457 + stable error codes + trace IDs).
19- Define AuthN/AuthZ boundaries (scopes/roles/tenancy) and threat model.
20- Define pagination/filter/sort for all list endpoints.
21- Define rate limits/quotas, idempotency strategy (esp. POST), and retries/backoff guidance.
22- Define observability (W3C Trace Context, request IDs, metrics, logs) and SLOs.
23- Add contract tests + breaking-change checks in CI.
24- Publish docs with examples + migration/deprecation policy.
25
26---
27
28## Quick Reference
29
30| Task | Pattern/Tool | Key Elements | When to Use |
31|------|--------------|--------------|-------------|
32| **Design REST API** | RESTful Design | Nouns (not verbs), HTTP methods, proper status codes | Resource-based APIs, CRUD operations |
33| **Version API** | URL Versioning | `/api/v1/resource`, `/api/v2/resource` | Breaking changes, client migration |
34| **Paginate results** | Cursor-Based | `cursor=eyJpZCI6MTIzfQ&limit=20` | Real-time data, large collections |
35| **Handle errors** | RFC 9457 Problem Details | `type`, `title`, `status`, `detail`, `errors[]` | Consistent error responses |
36| **Authenticate** | JWT Bearer | `Authorization: Bearer <token>` | Stateless auth, microservices |
37| **Rate limit** | Token Bucket | `X-RateLimit-*` headers, 429 responses | Prevent abuse, fair usage |
38| **Document API** | OpenAPI 3.1 | Swagger UI, Redoc, code samples | Interactive docs, client SDKs |
39| **Flexible queries** | GraphQL | Schema-first, resolvers, DataLoader | Client-driven data fetching |
40| **High-performance** | gRPC + Protobuf | Binary protocol, streaming | Internal microservices |
41| **TypeScript-first** | tRPC | End-to-end type safety, no codegen | Monorepos, internal tools |
42| **AI agent APIs** | REST + MCP | Agent experience, machine-readable | LLM/agent consumption |
43
44---
45
46## Decision Tree: Choosing API Style
47
48```text
49User needs: [API Type]
50 ├─ Public API for third parties?
51 │ └─ REST with OpenAPI docs (broad compatibility)
52 │
53 ├─ Internal microservices?
54 │ ├─ High throughput required? → **gRPC** (binary, fast)
55 │ └─ Simple CRUD? → **REST** (easy to debug)
56 │
57 ├─ TypeScript monorepo (frontend + backend)?
58 │ └─ **tRPC** (end-to-end type safety, no codegen)
59 │
60 ├─ Client needs flexible queries?
61 │ ├─ Real-time updates? → **GraphQL Subscriptions** or **WebSockets**
62 │ └─ Complex data fetching? → **GraphQL** (avoid over-fetching)
63 │
64 ├─ Mobile/web clients?
65 │ ├─ Many entity types? → **GraphQL** (single endpoint)
66 │ └─ Simple resources? → **REST** (cacheable)
67 │
68 ├─ AI agents consuming API?
69 │ └─ REST + **MCP** wrapper (agent experience)
70 │
71 └─ Streaming or bidirectional?
72 └─ **gRPC** (HTTP/2 streaming) or **WebSockets**
73```
74
75---
76
77## Navigation: Core API Patterns
78
79### RESTful API Design
80
81**Resource:** [references/restful-design-patterns.md](references/restful-design-patterns.md)
82
83- Resource-based URLs with proper HTTP methods (GET, POST, PUT, PATCH, DELETE)
84- HTTP status code semantics (200, 201, 404, 422, 500)
85- Idempotency guarantees (GET, PUT, DELETE)
86- Stateless design principles
87- URL structure best practices (collection vs resource endpoints)
88- Nested resources and action endpoints
89
90---
91
92### Pagination, Filtering & Sorting
93
94**Resource:** [references/pagination-filtering.md](references/pagination-filtering.md)
95
96- Offset-based pagination (simple, static datasets)
97- Cursor-based pagination (real-time feeds, recommended)
98- Page-based pagination (UI with page numbers)
99- Query parameter filtering with operators (`_gt`, `_contains`, `_in`)
100- Multi-field sorting with direction (`-created_at`)
101- Performance optimization with indexes
102
103---
104
105### Error Handling
106
107**Resource:** [references/error-handling-patterns.md](references/error-handling-patterns.md)
108
109- RFC 9457 Problem Details standard
110- HTTP status code reference (4xx client errors, 5xx server errors)
111- Field-level validation errors
112- Trace IDs for debugging
113- Consistent error format across endpoints
114- Security-safe error messages (no stack traces in production)
115
116---
117
118### Authentication & Authorization
119
120**Resource:** [references/authentication-patterns.md](references/authentication-patterns.md)
121
122- JWT (JSON Web Tokens) with refresh token rotation
123- OAuth2 Authorization Code Flow for third-party auth
124- API Key authentication for server-to-server
125- RBAC (Role-Based Access Control)
126- ABAC (Attribute-Based Access Control)
127- Resource-based authorization (user-owned resources)
128
129---
130
131### Rate Limiting & Throttling
132
133**Resource:** [references/rate-limiting-patterns.md](references/rate-limiting-patterns.md)
134
135- Token Bucket algorithm (recommended, allows bursts)
136- Fixed Window vs Sliding Window
137- Rate limit headers (`X-RateLimit-*`)
138- Tiered rate limits (free, paid, enterprise)
139- Redis-based distributed rate limiting
140- Per-user, per-endpoint, and per-API-key strategies
141
142---
143
144## Navigation: Extended Resources
145
146### API Design & Best Practices
147
148- **[api-design-best-practices.md](references/api-design-best-practices.md)** - Comprehensive API design principles
149- **[versioning-strategies.md](references/versioning-strategies.md)** - URL, header, and query parameter versioning
150- **[api-security-checklist.md](references/api-security-checklist.md)** - OWASP API Security Top 10
151
152### GraphQL & gRPC
153
154- **[graphql-patterns.md](references/graphql-patterns.md)** - Schema design, resolvers, N+1 queries, DataLoader
155- **gRPC patterns** - See [software-backend](../software-backend/SKILL.md) for Protocol Buffers and service definitions
156
157### tRPC (TypeScript-First)
158
159- **[trpc-patterns.md](references/trpc-patterns.md)** - End-to-end type safety, procedures, React Query integration
160 - When to use tRPC vs GraphQL vs REST
161 - Auth middleware patterns
162 - Server-side rendering with Next.js
163
164### OpenAPI & Documentation
165
166- **[openapi-guide.md](references/openapi-guide.md)** - OpenAPI 3.1 specifications, Swagger UI, Redoc
167- **Templates:** [assets/openapi-template.yaml](assets/openapi-template.yaml) - Complete OpenAPI spec example
168
169### Optional: AI/Automation (LLM/Agent APIs)
170
171- **[llm-agent-api-contracts.md](references/llm-agent-api-contracts.md)** - Streaming, long-running jobs, safety guardrails, observability
172
173---
174
175## Navigation: Templates
176
177Production-ready, copy-paste API implementations with authentication, database, validation, and docs.
178
179### Framework-Specific Templates
180
181- **FastAPI (Python)**: [assets/fastapi/fastapi-complete-api.md](assets/fastapi/fastapi-complete-api.md)
182 - Async/await, Pydantic v2, JWT auth, SQLAlchemy 2.0, pagination, OpenAPI docs
183
184- **Express.js (Node/TypeScript)**: [assets/express-nodejs/express-complete-api.md](assets/express-nodejs/express-complete-api.md)
185 - TypeScript, Zod validation, Prisma ORM, JWT refresh tokens, rate limiting
186
187- **Django REST Framework**: [assets/django-rest/django-rest-complete-api.md](assets/django-rest/django-rest-complete-api.md)
188 - ViewSets, serializers, Simple JWT, permissions, DRF filtering/pagination
189
190- **Spring Boot (Java)**: [assets/spring-boot/spring-boot-complete-api.md](assets/spring-boot/spring-boot-complete-api.md)
191 - Spring Security JWT, Spring Data JPA, Bean Validation, Springdoc OpenAPI
192
193### Cross-Platform Patterns
194
195- **[api-patterns-universal.md](assets/cross-platform/api-patterns-universal.md)** - Universal patterns for all frameworks
196 - Authentication strategies, pagination, caching, versioning, validation
197- **[template-api-governance.md](assets/cross-platform/template-api-governance.md)** - API governance, deprecation, multi-tenancy
198 - Deprecation policy (90-day timeline), backward compatibility rules, error model templates
199- **[template-api-design-review-checklist.md](assets/cross-platform/template-api-design-review-checklist.md)** - Production API review checklist (security, reliability, operability)
200- **[template-api-error-model.md](assets/cross-platform/template-api-error-model.md)** - RFC 9457 Problem Details + stable error code registry
201
202---
203
204## Do / Avoid
205
206### GOOD: Do
207
208- Version APIs from day one
209- Document deprecation policy before first deprecation
210- Treat breaking changes as a major version (and keep minor changes backward compatible)
211- Include trace IDs in all error responses
212- Return appropriate HTTP status codes
213- Implement rate limiting with clear headers
214- Use RFC 9457 Problem Details for errors
215
216### BAD: Avoid
217
218- Removing fields without deprecation period
219- Changing field types in existing versions
220- Using verbs in resource names (nouns only)
221- Returning 500 for client errors
222- Breaking changes without major version bump
223- Mixing tenant data without explicit isolation
224- Action endpoints everywhere (/doSomething)
225
226---
227
228## Anti-Patterns
229
230| Anti-Pattern | Problem | Fix |
231|--------------|---------|-----|
232| **Instant deprecation** | Breaks clients | 90-day minimum sunset period |
233| **Action endpoints** | Inconsistent API | Use resources + HTTP verbs |
234| **Version in body** | Hard to route, debug | Version in URL or header |
235| **Generic errors** | Poor DX | Specific error codes + messages |
236| **No rate limit headers** | Clients can't back off | Include X-RateLimit-* |
237| **Tenant ID in URL only** | Forgery risk | Validate against auth token |
238| **Leaky abstractions** | Tight coupling | Design stable contracts |
239
240---
241
242## Optional: AI/Automation
243
244> **Note**: AI tools assist but contracts need human review.
245
246- **OpenAPI linting** — Spectral, Redocly in CI/CD
247- **Breaking change detection** — oasdiff automated checks
248- **SDK generation** — From OpenAPI spec on changes
249- **Contract testing** — Pact, Dredd automation
250
251### Bounded Claims
252
253- AI-generated OpenAPI specs require human review
254- Automated deprecation detection needs manual confirmation
255- SDK generation requires type verification
256
257---
258
259## External Resources
260
261See [data/sources.json](data/sources.json) for:
262
263- Official REST, GraphQL, gRPC documentation
264- OpenAPI/Swagger tools and validators
265- API design style guides (Google, Microsoft, Stripe)
266- Security standards (OWASP API Security Top 10)
267- Testing tools (Postman, Insomnia, Paw)
268
269---
270
271## Related Skills
272
273This skill works best when combined with other specialized skills:
274
275### Backend Development
276
277- **[software-backend](../software-backend/SKILL.md)** - Production backend patterns (Node.js, Python, Java frameworks)
278 - Use when implementing API server infrastructure
279 - Covers database integration, middleware, error handling
280
281### Security & Authentication
282
283- **[software-security-appsec](../software-security-appsec/SKILL.md)** - Application security patterns
284 - Critical for securing API endpoints
285 - Covers OWASP vulnerabilities, authentication flows, input validation
286
287### Database & Data Layer
288
289- **[data-sql-optimization](../data-sql-optimization/SKILL.md)** - SQL optimization and database patterns
290 - Essential for API performance (query optimization, indexing)
291 - Use when APIs interact with relational databases
292
293### Testing & Quality
294
295- **[qa-testing-strategy](../qa-testing-strategy/SKILL.md)** - Test strategy and automation
296 - Contract testing for API specifications
297 - Integration testing for API endpoints
298
299### DevOps & Deployment
300
301- **[ops-devops-platform](../ops-devops-platform/SKILL.md)** - Platform engineering and deployment
302 - API gateway configuration
303 - CI/CD pipelines for API deployments
304
305### Documentation
306
307- **[docs-codebase](../docs-codebase/SKILL.md)** - Technical documentation standards
308 - API reference documentation structure
309 - Complements OpenAPI auto-generated docs
310
311### Architecture
312
313- **[software-architecture-design](../software-architecture-design/SKILL.md)** - System design patterns
314 - Microservices architecture with APIs
315 - API gateway patterns, service mesh integration
316
317### Performance & Observability
318
319- **[qa-observability](../qa-observability/SKILL.md)** - Performance optimization and monitoring
320 - API latency monitoring, distributed tracing
321 - Performance budgets for API endpoints
322
323---
324
325## Usage Notes
326
327**For the agent:**
328
329- Apply RESTful principles by default unless user requests GraphQL/gRPC
330- Always include pagination for list endpoints
331- Use RFC 9457 format for error responses
332- Include authentication in all templates (JWT or API keys)
333- Reference framework-specific templates for complete implementations
334- Link to relevant resources for deep-dive guidance
335
336**Success Criteria:** APIs are discoverable, consistent, well-documented, secure, and follow HTTP/GraphQL semantics correctly.
337
338---
339
340## Time-Sensitive Recommendations
341
342If a user asks for "best" tools/frameworks, "latest" standards, or whether something is still relevant in 2026, do a quick web search using whatever browsing/search tool is available in the current environment. If web access is unavailable, answer from stable principles, state assumptions (traffic, latency, team skills, ecosystem), and avoid overstating currency.