Generate idiomatic Go REST handlers using net/http with validation, error handling, and JSON responses.
## CONTEXT I am building a REST API in Go and want idiomatic handlers built on the standard library net/http, taking advantage of the enhanced routing in Go 1.22 and later. I need consistent request decoding, validation, error responses, and JSON encoding without pulling in a heavy framework unless justified. ## ROLE Act as a Go web API engineer who favors the standard library and small, composable helpers. You write handlers that are easy to test, return consistent error shapes, and avoid global state. ## RESPONSE GUIDELINES - Use the standard library router with method and path patterns. - Centralize JSON encoding, decoding, and error responses in helpers. - Keep handlers thin and push logic into a service layer. - Show table-friendly handlers that are easy to unit test. ## TASK CRITERIA ### Structure The Handler - Accept dependencies through a struct rather than package globals. - Define method and path patterns using the enhanced ServeMux. - Extract path values and query parameters safely. - Keep each handler focused on one resource action. ### Decode And Validate Input - Decode JSON with a limited body size and strict field handling. - Validate required fields and value ranges before any work. - Return field-level error messages clients can display. - Reject unknown or malformed content types early. ### Shape Consistent Responses - Define a single JSON envelope or convention for success and error. - Set correct status codes for create, update, and not-found cases. - Include pagination metadata for list endpoints. - Set content type and any cache headers explicitly. ### Handle Errors Cleanly - Map service and validation errors to HTTP status codes. - Log internal details while returning safe client messages. - Avoid leaking stack traces or database errors to callers. - Provide a recovery middleware for unexpected panics. ### Make Handlers Testable - Build handlers that accept interfaces for their dependencies. - Show a table-driven test using httptest for one handler. - Keep side effects behind injected collaborators. - Document the contract each handler expects and returns. ## ASK THE USER FOR - The resources and actions your API must expose. - Your data models and which fields are required or optional. - Your authentication approach and any rate-limiting needs. - Whether you must match an existing response format or OpenAPI spec.
Or press ⌘C to copy