Generate Go client and server boilerplate from OpenAPI 3 specifications to reduce manual coding.
oapi-codegen is a Go tool that generates boilerplate code from OpenAPI 3.0 specifications. It automates the creation of server implementations, API clients, and data models, reducing the manual effort required to build or integrate with RESTful APIs. The tool supports multiple Go HTTP frameworks and helps ensure consistency between API specifications and implementation.
Go developers building or consuming RESTful APIs defined with OpenAPI 3.0, particularly those working in teams that value contract-first development and want to reduce boilerplate code.
Developers choose oapi-codegen because it generates idiomatic Go code, supports a wide range of HTTP frameworks, and reduces the risk of inconsistencies between API specs and implementation. Its focus on simplicity and comprehensive OpenAPI support makes it a reliable choice for production use.
Generate Go client and server boilerplate from OpenAPI 3 specifications
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Generates server code for multiple popular Go HTTP frameworks like Chi, Echo, Fiber, Gin, and gorilla/mux, making it adaptable to various project setups without lock-in to a single ecosystem.
Automates parameter extraction, marshalling, and error handling in generated server and client code, allowing developers to focus on implementing business logic rather than repetitive plumbing.
Offers a strict server option that further reduces boilerplate by auto-handling request/response (un)marshalling and providing context-based interfaces, inspired by RPC-style code generation.
Supports splitting large OpenAPI specs across multiple Go packages using external references, enabling better code organization for complex APIs without bundling everything into one file.
Does not support OpenAPI 2.0 (Swagger), and OpenAPI 3.1 support is only experimental via a separate repository, limiting compatibility with newer or legacy specifications.
Relies on YAML configuration files and features like import mapping and OpenAPI overlays, which can be complex to set up and maintain, especially for simple APIs or teams new to code generation.
Client generation can produce duplicate type names if schemas are named similarly to operation IDs (e.g., '*Request' or '*Response'), requiring extra configuration like 'response-type-suffix' to resolve.
The project lacks a defined release schedule, as admitted in the README, leading to recommendations to pin to commits for unreleased changes and potential instability in version management.