一键导入
api-design
REST API design best practices: resource naming, versioning, error handling, pagination, HATEOAS, rate limiting, OpenAPI documentation. Trigger: API design, REST API, endpoint, OpenAPI, RESTful, API versioning, or API documentation.
菜单
REST API design best practices: resource naming, versioning, error handling, pagination, HATEOAS, rate limiting, OpenAPI documentation. Trigger: API design, REST API, endpoint, OpenAPI, RESTful, API versioning, or API documentation.
Pre-built UI component libraries for server-rendered HTML: Preline UI, HyperUI, Flowbite. Modals, tables, forms, navbars, dropdowns — no React, no build step. Trigger: UI components, component library, Preline, HyperUI, Flowbite, Tailwind CSS components, pre-built UI.
Server-side web UI with Spring Boot: Thymeleaf templates, HTMX for dynamic interactions, Alpine.js for client-side behavior. No React, no webpack. Trigger: Thymeleaf, HTMX, Alpine.js, Spring MVC template, server-side rendering, web UI.
Docker and containerization best practices: multi-stage builds, docker-compose, networking, volumes, security, and image optimization. Trigger: Docker, Dockerfile, docker-compose, container, image build, or containerization.
General database design principles: modeling, normalization, indexing, naming conventions, migrations, and query optimization. Trigger: Database design, data modeling, schema design, table design, or migration planning.
Comprehensive best practices for developing high-quality Spring Boot applications with production-ready patterns. Trigger: When developing Spring Boot applications, need best practices, or working with Spring framework.
Expert Spring Boot testing specialist that selects the best testing techniques for your situation with JUnit and AssertJ. Trigger: When writing Spring Boot tests, need testing patterns, or working with test slices.
| name | api-design |
| description | REST API design best practices: resource naming, versioning, error handling, pagination, HATEOAS, rate limiting, OpenAPI documentation. Trigger: API design, REST API, endpoint, OpenAPI, RESTful, API versioning, or API documentation. |
| license | Apache-2.0 |
| metadata | {"author":"vekzz-dev","version":"1.0"} |
| Pattern | Example | Notes |
|---|---|---|
GET /resources | GET /users | List collection |
POST /resources | POST /users | Create (return 201 + Location header) |
GET /resources/:id | GET /users/42 | Single resource |
PUT /resources/:id | PUT /users/42 | Full replace |
PATCH /resources/:id | PATCH /users/42 | Partial update |
DELETE /resources/:id | DELETE /users/42 | Delete |
GET /resources/:id/subresources | GET /users/42/orders | Sub-collection |
POST /resources/:id/subresources | POST /users/42/orders | Create sub-resource |
Rules:
/users not /getUserskebab-case or snake_case, not mixedPOST /orders/42/cancel| Strategy | How | Pros | Cons |
|---|---|---|---|
| URI path | GET /v1/users | Explicit, cacheable, easy to route | URL pollution on breaking changes |
| Header | Accept: application/vnd.myapp.v1+json | Clean URLs, content negotiation | Harder to discover, caching complexity |
| Query param | GET /users?version=1 | Easy to test | Pollutes query space, not cache-friendly |
Recommendation: URI path for public APIs, header for internal/microservices.
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/problem+json
{
"type": "https://api.example.com/errors/order/invalid-status",
"title": "Invalid order status transition",
"status": 422,
"detail": "Cannot transition order 42 from 'shipped' to 'pending'.",
"instance": "/orders/42",
"timestamp": "2025-05-31T10:30:00Z"
}
Always use consistent error envelope. Map HTTP status codes semantically:
| Code | When |
|---|---|
| 400 | Malformed request body / validation error |
| 401 | Missing or invalid authentication |
| 403 | Authenticated but not authorized |
| 404 | Resource not found |
| 409 | Conflict (duplicate, stale version) |
| 422 | Unprocessable entity (business rule violation) |
| 429 | Rate limited |
| 500 | Unexpected server error (never leak details) |
Never return 5xx for client errors or 4xx for server faults.
Cursor-based (preferred for large datasets):
GET /users?cursor=eyJpZCI6NDJ9&limit=20
{
"data": [...],
"pagination": {
"next": "eyJpZCI6NjJ9",
"limit": 20
}
}
Offset-based (acceptable for small/admin datasets):
GET /users?page=1&size=20
{
"data": [...],
"pagination": {
"page": 1,
"size": 20,
"total": 150,
"total_pages": 8
}
}
Guide clients via links in responses — they don't hardcode URLs:
GET /orders/42
{
"id": 42,
"status": "pending",
"_links": {
"self": { "href": "/orders/42" },
"cancel": { "href": "/orders/42/cancel", "method": "POST" },
"pay": { "href": "/orders/42/pay", "method": "POST" }
}
}
Spring Boot: org.springframework.boot:spring-boot-starter-hateoas
| Strategy | How | Best for |
|---|---|---|
| Token bucket | Fixed rate, burst allowed | General purpose |
| Sliding window | Rolling time window | Strict rate enforcement |
| Leaky bucket | Smooth output rate | Queue processing |
Response headers:
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1717142400
Use springdoc-openapi (springdoc-openapi-starter-webmvc-ui for Boot 3+):
@Operation(summary = "List all users", description = "Returns paginated list of active users")
@ApiResponse(responseCode = "200", description = "Users found")
@ApiResponse(responseCode = "401", description = "Unauthorized")
@GetMapping
public ResponseEntity<Page<UserResponse>> listUsers(
@Parameter(description = "Cursor for pagination") @RequestParam(required = false) String cursor
) { ... }
Annotate every endpoint — don't rely on auto-generated names.
/api prefix on every route — api.example.com or gateway takes care of it/a/1/b/2/c/3/d/4 is unreadable; use query params@ControllerAdvice to sanitize/getAllUsers — REST uses HTTP methods, not verbs in the URL# Generate OpenAPI spec at runtime
curl localhost:8080/v3/api-docs | jq .
# OpenAPI UI
open http://localhost:8080/swagger-ui.html