78 lines
2.2 KiB
Markdown
78 lines
2.2 KiB
Markdown
# Copilot Prompt for Rust Image Manipulation API
|
|
|
|
You are working on a Rust API project built with:
|
|
- Axum 0.8.8
|
|
- SeaORM 1.1.20 with PostgreSQL
|
|
- Tokio full runtime
|
|
- tower-http trace
|
|
|
|
The project already has an account system. Do not redesign it unless asked.
|
|
|
|
## Main Goal
|
|
Build an image manipulation API that:
|
|
- supports `avif`, `png`, `jpg`, `jpeg`, `webp`
|
|
- accepts `width`, `height`, `format`, `quality`, and `crop`
|
|
- supports crop modes like `cover` and other common crop strategies
|
|
- uses time-limited access tokens for protected image operations
|
|
- uses Redis for token validation and temporary access control
|
|
|
|
## Important Constraints
|
|
- Use idiomatic Rust
|
|
- Follow Axum conventions
|
|
- Keep business logic in services
|
|
- Keep DB and Redis logic in repositories
|
|
- Use SeaORM for database access
|
|
- Validate all inputs
|
|
- Return structured JSON errors
|
|
- Do not panic in handlers
|
|
- Do not expose internal file paths or secrets
|
|
|
|
## Implementation Guidance
|
|
When generating or modifying code:
|
|
1. Split code by module:
|
|
- controller/handler
|
|
- service
|
|
- repository
|
|
- dto
|
|
- model
|
|
- processor
|
|
|
|
2. For image processing:
|
|
- decode input image
|
|
- validate requested dimensions and format
|
|
- apply crop/resize strategy
|
|
- convert to requested output format
|
|
- encode with requested quality
|
|
- return the transformed image
|
|
|
|
3. For token access:
|
|
- read token from request
|
|
- verify token in Redis
|
|
- reject expired/invalid tokens
|
|
- proceed only if valid
|
|
|
|
4. For API design:
|
|
- keep routes clean and versioned if needed
|
|
- use consistent request/response shapes
|
|
- add tracing/logging where useful
|
|
|
|
## Default Behaviors
|
|
- default format: `webp`
|
|
- default crop: `cover`
|
|
- default quality: `80`
|
|
- if only width or only height is provided, preserve aspect ratio when possible
|
|
|
|
## Output Expectations
|
|
When asked to generate code:
|
|
- provide complete Rust code snippets
|
|
- include file names
|
|
- keep code ready to integrate
|
|
- minimize unnecessary abstractions
|
|
- match the existing codebase style
|
|
|
|
## If there is ambiguity
|
|
Prefer:
|
|
- safe validation over permissive behavior
|
|
- explicit errors over silent fallback
|
|
- modular design over monolithic handlers
|
|
- Redis-backed token checks over in-memory shortcuts |