{"id":37190735,"url":"https://github.com/chanced/oapi-codegen","last_synced_at":"2026-01-14T22:02:00.589Z","repository":{"id":57747805,"uuid":"521772274","full_name":"chanced/oapi-codegen","owner":"chanced","description":"Generate Go client and server boilerplate from OpenAPI 3 specifications","archived":false,"fork":true,"pushed_at":"2022-08-06T02:13:02.000Z","size":8400,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"master","last_synced_at":"2024-06-20T12:02:25.061Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":"oapi-codegen/oapi-codegen","license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/chanced.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2022-08-05T20:47:25.000Z","updated_at":"2024-06-05T08:56:11.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/chanced/oapi-codegen","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/chanced/oapi-codegen","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chanced%2Foapi-codegen","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chanced%2Foapi-codegen/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chanced%2Foapi-codegen/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chanced%2Foapi-codegen/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/chanced","download_url":"https://codeload.github.com/chanced/oapi-codegen/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/chanced%2Foapi-codegen/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28436268,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-14T21:32:52.117Z","status":"ssl_error","status_checked_at":"2026-01-14T21:32:33.442Z","response_time":107,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-01-14T22:01:59.672Z","updated_at":"2026-01-14T22:02:00.509Z","avatar_url":"https://github.com/chanced.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"OpenAPI Client and Server Code Generator\n----------------------------------------\n\nThis package contains a set of utilities for generating Go boilerplate code for\nservices based on\n[OpenAPI 3.0](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md)\nAPI definitions. When working with services, it's important to have an API\ncontract which servers and clients both implement to minimize the chances of\nincompatibilities. It's tedious to generate Go models which precisely correspond to\nOpenAPI specifications, so let our code generator do that work for you, so that\nyou can focus on implementing the business logic for your service.\n\nWe have chosen to focus on [Echo](https://github.com/labstack/echo) as\nour default HTTP routing engine, due to its speed and simplicity for the generated\nstubs, and [Chi](https://github.com/go-chi/chi), and [Gin](https://github.com/gin-gonic/gin)\nhave also been added by contributors as additional routers. We chose Echo because\nthe `Context` object is a mockable interface, and it allows for some advanced\ntesting.\n\nThis package tries to be too simple rather than too generic, so we've made some\ndesign decisions in favor of simplicity, knowing that we can't generate strongly\ntyped Go code for all possible OpenAPI Schemas. If there is a way to accomplish\nsomething via utility code or reflection, it's probably a better approach than\ncode generation, which is fragile due to the very dynamic nature of OpenAPI and\nthe very static nature of Go.\n\n## Overview\n\nWe're going to use the OpenAPI example of the\n[Expanded Petstore](https://github.com/OAI/OpenAPI-Specification/blob/master/examples/v3.0/petstore-expanded.yaml)\nin the descriptions below, please have a look at it.\n\nIn order to create a Go server to serve this exact schema, you would have to\nwrite a lot of boilerplate code to perform all the marshalling and unmarshalling\ninto objects which match the OpenAPI 3.0 definition. The code generator in this\ndirectory does a lot of that for you. You would run it like so:\n\n    go install github.com/deepmap/oapi-codegen/cmd/oapi-codegen@latest\n    oapi-codegen petstore-expanded.yaml \u003e petstore.gen.go\n\nLet's go through that `petstore.gen.go` file to show you everything which was\ngenerated.\n\n\n## Generated Server Boilerplate\n\nThe `/components/schemas` section in OpenAPI defines reusable objects, so Go\ntypes are generated for these. The Pet Store example defines `Error`, `Pet`,\n`Pets` and `NewPet`, so we do the same in Go:\n```go\n// Error defines model for Error.\ntype Error struct {\n    // Error code\n    Code int32 `json:\"code\"`\n\n    // Error message\n    Message string `json:\"message\"`\n}\n\n// NewPet defines model for NewPet.\ntype NewPet struct {\n    // Name of the pet\n    Name string `json:\"name\"`\n\n    // Type of the pet\n    Tag *string `json:\"tag,omitempty\"`\n}\n\n// Pet defines model for Pet.\ntype Pet struct {\n    // Unique id of the pet\n    Id int64 `json:\"id\"`\n\n    // Name of the pet\n    Name string `json:\"name\"`\n\n    // Type of the pet\n    Tag *string `json:\"tag,omitempty\"`\n}\n\n// Type definition for component schema \"Pets\"\ntype Pets []Pet\n```\n\nIt's best to define objects under `/components` field in the schema, since\nthose will be turned into named Go types. If you use inline types in your\nhandler definitions, we will generate inline, anonymous Go types, but those\nare more tedious to deal with since you will have to redeclare them at every\npoint of use.\n\nFor each element in the `paths` map in OpenAPI, we will generate a Go handler\nfunction in an interface object. Here is the generated Go interface for our\nEcho server.\n\n```go\ntype ServerInterface interface {\n    //  (GET /pets)\n    FindPets(ctx echo.Context, params FindPetsParams) error\n    //  (POST /pets)\n    AddPet(ctx echo.Context) error\n    //  (DELETE /pets/{id})\n    DeletePet(ctx echo.Context, id int64) error\n    //  (GET /pets/{id})\n    FindPetById(ctx echo.Context, id int64) error\n}\n```\n\nThese are the functions which you will implement yourself in order to create\na server conforming to the API specification. Normally, all the arguments and\nparameters are stored on the `echo.Context` in handlers, so we do the tedious\nwork of of unmarshaling the JSON automatically, simply passing values into\nyour handlers.\n\nNotice that `FindPetById` takes a parameter `id int64`. All path arguments\nwill be passed as arguments to your function, since they are mandatory.\n\nRemaining arguments can be passed in headers, query arguments or cookies. Those\nwill be written to a `params` object. Look at the `FindPets` function above, it\ntakes as input `FindPetsParams`, which is defined as follows:\n ```go\n// Parameters object for FindPets\ntype FindPetsParams struct {\n    Tags  *[]string `json:\"tags,omitempty\"`\n    Limit *int32   `json:\"limit,omitempty\"`\n}\n```\n\nThe HTTP query parameter `limit` turns into a Go field named `Limit`. It is\npassed by pointer, since it is an optional parameter. If the parameter is\nspecified, the pointer will be non-`nil`, and you can read its value.\n\nIf you changed the OpenAPI specification to make the parameter required, the\n`FindPetsParams` structure will contain the type by value:\n```go\ntype FindPetsParams struct {\n    Tags  *[]string `json:\"tags,omitempty\"`\n    Limit int32     `json:\"limit\"`\n}\n```\n\n### Registering handlers\nThere are a few ways of registering your http handler based on the type of server generated i.e. `-generate server` or `-generate chi-server`\n\n\u003cdetails\u003e\u003csummary\u003e\u003ccode\u003eEcho\u003c/code\u003e\u003c/summary\u003e\n\nCode generated using `-generate server`.\n\nThe usage of `Echo` is out of scope of this doc, but once you have an\necho instance, we generate a utility function to help you associate your handlers\nwith this autogenerated code. For the pet store, it looks like this:\n```go\nfunc RegisterHandlers(router codegen.EchoRouter, si ServerInterface) {\n    wrapper := ServerInterfaceWrapper{\n        Handler: si,\n    }\n    router.GET(\"/pets\", wrapper.FindPets)\n    router.POST(\"/pets\", wrapper.AddPet)\n    router.DELETE(\"/pets/:id\", wrapper.DeletePet)\n    router.GET(\"/pets/:id\", wrapper.FindPetById)\n}\n```\n\nThe wrapper functions referenced above contain generated code which pulls\nparameters off the `Echo` request context, and unmarshals them into Go objects.\n\nYou would register the generated handlers as follows:\n```go\nfunc SetupHandler() {\n    var myApi PetStoreImpl  // This implements the pet store interface\n    e := echo.New()\n    petstore.RegisterHandlers(e, \u0026myApi)\n    ...\n}\n```\n\n\u003c/summary\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003e\u003ccode\u003eChi\u003c/code\u003e\u003c/summary\u003e\n\nCode generated using `-generate chi-server`.\n\n```go\ntype PetStoreImpl struct {}\nfunc (*PetStoreImpl) GetPets(w http.ResponseWriter, r *http.Request) {\n    // Implement me\n}\n\nfunc SetupHandler() {\n    var myApi PetStoreImpl\n\n    r := chi.NewRouter()\n    r.Mount(\"/\", Handler(\u0026myApi))\n}\n```\n\u003c/summary\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003e\u003ccode\u003eGin\u003c/code\u003e\u003c/summary\u003e\n\nCode generated using `-generate gin`.\n\nThe usage of `gin` is out of scope of this doc, but once you have an\ngin instance, we generate a utility function to help you associate your handlers\nwith this autogenerated code. For the pet store, it looks like this:\n```go\n// RegisterHandlersWithOptions creates http.Handler with additional options\nfunc RegisterHandlersWithOptions(router *gin.Engine, si ServerInterface, options GinServerOptions) *gin.Engine {\n\twrapper := ServerInterfaceWrapper{\n\t\tHandler:            si,\n\t\tHandlerMiddlewares: options.Middlewares,\n\t}\n\n\trouter.GET(options.BaseURL+\"/pets\", wrapper.FindPets)\n\trouter.POST(options.BaseURL+\"/pets\", wrapper.AddPet)\n\trouter.DELETE(options.BaseURL+\"/pets/:id\", wrapper.DeletePet)\n\trouter.GET(options.BaseURL+\"/pets/:id\", wrapper.FindPetByID)\n\treturn router\n}\n```\n\n```go\nimport (\n\t\"github.com/gin-gonic/gin\"\n\t\"github.com/deepmap/oapi-codegen/examples/petstore-expanded/gin/api\"\n\tmiddleware \"github.com/deepmap/oapi-codegen/pkg/gin-middleware\"\n)\n\ntype PetStoreImpl struct {}\nfunc (*PetStoreImpl) GetPets(w http.ResponseWriter, r *http.Request) {\n    // Implement me\n}\n\nfunc SetupHandler() {\n    var myApi PetStoreImpl\n\n    r := gin.Default()\n\t  r.Use(middleware.OapiRequestValidator(swagger))\n    r = api.RegisterHandlers(r, petStore)\n}\n```\n\u003c/summary\u003e\u003c/details\u003e\n\n\u003cdetails\u003e\u003csummary\u003e\u003ccode\u003enet/http\u003c/code\u003e\u003c/summary\u003e\n\n[Chi](https://github.com/go-chi/chi) is 100% compatible with `net/http` allowing the following with code generated using `-generate chi-server`.\n\n```go\ntype PetStoreImpl struct {}\nfunc (*PetStoreImpl) GetPets(w http.ResponseWriter, r *http.Request) {\n    // Implement me\n}\n\nfunc SetupHandler() {\n    var myApi PetStoreImpl\n\n    http.Handle(\"/\", Handler(\u0026myApi))\n}\n```\n\nAlternatively, [Gorilla](https://github.com/gorilla/mux) is also 100% compatible with `net/http` and can be generated with `-generate gorilla`.\n\n\u003c/summary\u003e\u003c/details\u003e\n\n#### Strict server generation\n\noapi-codegen also supports generating RPC inspired strict server, that will parse request bodies and encode responses. \nThe main points of this code is to automate some parsing, abstract user code from server specific code, \nand also to force user code to comply with the schema.\nIt supports binding of `application/json` and `application/x-www-form-urlencoded` to a struct, for `multipart` requests\nit generates a `multipart.Reader`, which can be used to either manually iterating over parts or using `runtime.BindMultipart`\nfunction to bind the form to a struct. All other content types are represented by a `io.Reader` interface.\n\nTo form a response simply return one of the generated structs with corresponding status code and content type. For example,\nto return a status code 200 JSON response for a AddPet use the `AddPet200JSONResponse` struct which will set the correct\nContent-Type header, status code and will marshal the response data. You can also return an `error` interface, that will be\ncause an `Internal Server Error` response. If you return a response that is not supported by this method, you will get an error.\nUnfortunately go does not support union types outside generic code, so we can't type check in compile time.\n\nShort example:\n```go\ntype PetStoreImpl struct {}\nfunc (*PetStoreImpl) GetPets(ctx context.Context, request GetPetsRequestObject) interface{} {\n    var result []Pet\n\t// Implement me\n    return GetPets200JSONResponse(result)\n}\n```\nFor a complete example see `/examples/petstore-expanded/strict`.\n\nCode is generation with a configuration flag `genrate: strict-server: true` along with any other server (echo, chi, gin and gorilla are supported).\nThe generated strict wrapper can then be used as an implementation for `ServerInterface`. Setup example:\n```go\nfunc SetupHandler() {\n    var myApi PetStoreImpl\n\tmyStrictApiHandler := api.NewStrictHandler(myApi, nil)\n    e := echo.New()\n    petstore.RegisterHandlers(e, \u0026myStrictApiHandler)\n}\n```\n\nStrict server also has its own middlewares. It can access to both request and response structs,\nas well as raw request\\response data. It can be used for logging the parsed request\\response objects, transforming go errors into response structs,\nauthorization, etc. Note that middlewares are server-specific.\n\n#### Additional Properties in type definitions\n\n[OpenAPI Schemas](https://swagger.io/specification/#schemaObject) implicitly\naccept `additionalProperties`, meaning that any fields provided, but not explicitly\ndefined via properties on the schema are accepted as input, and propagated. When\nunspecified, the `additionalProperties` field is assumed to be `true`.\n\nAdditional properties are tricky to support in Go with typing, and require\nlots of boilerplate code, so in this library, we assume that `additionalProperties`\ndefaults to `false` and we don't generate this boilerplate. If you would like\nan object to accept `additionalProperties`, specify a schema for `additionalProperties`.\n\nSay we declared `NewPet` above like so:\n```yaml\n    NewPet:\n      required:\n        - name\n      properties:\n        name:\n          type: string\n        tag:\n          type: string\n      additionalProperties:\n        type: string\n```\n\nThe Go code for `NewPet` would now look like this:\n```go\n// NewPet defines model for NewPet.\ntype NewPet struct {\n\tName                 string            `json:\"name\"`\n\tTag                  *string           `json:\"tag,omitempty\"`\n\tAdditionalProperties map[string]string `json:\"-\"`\n}\n```\n\nThe additionalProperties, of type `string` become `map[string]string`, which maps\nfield names to instances of the `additionalProperties` schema.\n```go\n// Getter for additional properties for NewPet. Returns the specified\n// element and whether it was found\nfunc (a NewPet) Get(fieldName string) (value string, found bool) {...}\n\n// Setter for additional properties for NewPet\nfunc (a *NewPet) Set(fieldName string, value string) {...}\n\n// Override default JSON handling for NewPet to handle additionalProperties\nfunc (a *NewPet) UnmarshalJSON(b []byte) error {...}\n\n// Override default JSON handling for NewPet to handle additionalProperties\nfunc (a NewPet) MarshalJSON() ([]byte, error) {...}w\n```\n\nThere are many special cases for `additionalProperties`, such as having to\ndefine types for inner fields which themselves support additionalProperties, and\nall of them are tested via the `internal/test/components` schemas and tests. Please\nlook through those tests for more usage examples.\n\n#### oneOf/anyOf/allOf support\n\n- `oneOf` and `anyOf` are implemented using delayed parsing with the help of `json.RawMessage`.\nThe following schema will result in a type that has methods such as `AsCat`, `AsDog`, `FromCat`, `FromDog`, `MergeCat`, `MergeDog`. If the schema also includes a discriminator the generated code will also have methods such as `Discriminator`, `ValueByDiscriminator` and will force discriminator value in `From` methods.\n```yaml\nschema:\n  oneOf:\n    - $ref: '#/components/schemas/Cat'\n    - $ref: '#/components/schemas/Dog'\n```\n- `allOf` is supported, by taking the union of all the fields in all the\n    component schemas. This is the most useful of these operations, and is\n    commonly used to merge objects with an identifier, as in the\n    `petstore-expanded` example.\n\n## Generated Client Boilerplate\n\nOnce your server is up and running, you probably want to make requests to it. If\nyou're going to do those requests from your Go code, we also generate a client\nwhich is conformant with your schema to help in marshaling objects to JSON. It\nuses the same types and similar function signatures to your request handlers.\n\nThe interface for the pet store looks like this:\n\n```go\n// The interface specification for the client above.\ntype ClientInterface interface {\n\n\t// FindPets request\n\tFindPets(ctx context.Context, params *FindPetsParams, reqEditors ...RequestEditorFn) (*http.Response, error)\n\n\t// AddPet request with JSON body\n\tAddPet(ctx context.Context, body NewPet, reqEditors ...RequestEditorFn) (*http.Response, error)\n\n\t// DeletePet request\n\tDeletePet(ctx context.Context, id int64, reqEditors ...RequestEditorFn) (*http.Response, error)\n\n\t// FindPetById request\n\tFindPetById(ctx context.Context, id int64, reqEditors ...RequestEditorFn) (*http.Response, error)\n}\n```\n\nA Client object which implements the above interface is also generated:\n\n```go\n// Client which conforms to the OpenAPI3 specification for this service.\ntype Client struct {\n    // The endpoint of the server conforming to this interface, with scheme,\n    // https://api.deepmap.com for example.\n    Server string\n\n    // HTTP client with any customized settings, such as certificate chains.\n    Client http.Client\n\n    // A callback for modifying requests which are generated before sending over\n    // the network.\n    RequestEditors []func(ctx context.Context, req *http.Request) error\n}\n```\n\nEach operation in your OpenAPI spec will result in a client function which\ntakes the same arguments. It's difficult to handle any arbitrary body that\nSwagger supports, so we've done some special casing for bodies, and you may get\nmore than one function for an operation with a request body.\n\n1) If you have more than one request body type, meaning more than one media\n type, you will have a generic handler of this form:\n\n        AddPet(ctx context.Context, contentType string, body io.Reader)\n\n2) If you have only a JSON request body, you will get:\n\n        AddPet(ctx context.Context, body NewPet)\n\n3) If you have multiple request body types, which include a JSON type you will\n get two functions. We've chosen to give the JSON version a shorter name, as\n we work with JSON and don't want to wear out our keyboards.\n\n        AddPet(ctx context.Context, body NewPet)\n        AddPetWithBody(ctx context.Context, contentType string, body io.Reader)\n\nThe Client object above is fairly flexible, since you can pass in your own\n`http.Client` and a request editing callback. You can use that callback to add\nheaders. In our middleware stack, we annotate the context with additional\ninformation such as the request ID and function tracing information, and we\nuse the callback to propagate that information into the request headers. Still, we\ncan't foresee all possible usages, so those functions call through to helper\nfunctions which create requests. In the case of the pet store, we have:\n\n```go\n// Request generator for FindPets\nfunc NewFindPetsRequest(server string, params *FindPetsParams) (*http.Request, error) {...}\n\n// Request generator for AddPet with JSON body\nfunc NewAddPetRequest(server string, body NewPet) (*http.Request, error) {...}\n\n// Request generator for AddPet with non-JSON body\nfunc NewAddPetRequestWithBody(server string, contentType string, body io.Reader) (*http.Request, error) {...}\n\n// Request generator for DeletePet\nfunc NewDeletePetRequest(server string, id int64) (*http.Request, error) {...}\n\n// Request generator for FindPetById\nfunc NewFindPetByIdRequest(server string, id int64) (*http.Request, error) {...}\n```\n\nYou can call these functions to build an `http.Request` from Go objects, which\nwill correspond to your request schema. They map one-to-one to the functions on\nthe client, except that we always generate the generic non-JSON body handler.\n\nThere are some caveats to using this code.\n- exploded, form style query arguments, which are the default argument format\n in OpenAPI 3.0 are undecidable. Say that I have two objects, one composed of\n the fields `(name=bob, id=5)` and another which has `(name=shoe, color=brown)`.\n The first parameter is named `person` and the second is named `item`. The\n default marshaling style for query args would result in\n `/path/?name=bob,id=5\u0026name=shoe,color=brown`. In order to tell what belongs\n to which object, we'd have to look at all the parameters and try to deduce it,\n but we're lazy, so we didn't. Don't use exploded form style arguments if\n you're passing around objects which have similar field names. If you\n used unexploded form parameters, you'd have\n `/path/?person=name,bob,id,5\u0026item=name,shoe,color,brown`, which an be\n parsed unambiguously.\n\n- Parameters can be defined via `schema` or via `content`. Use the `content` form\n for anything other than trivial objects, they can marshal to arbitrary JSON\n structures. When you send them as cookie (`in: cookie`) arguments, we will\n URL encode them, since JSON delimiters aren't allowed in cookies.\n\n## Using SecurityProviders\n\nIf you generate client-code, you can use some default-provided security providers\nwhich help you to use the various OpenAPI 3 Authentication mechanism.\n\n\n```go\n    import (\n        \"github.com/deepmap/oapi-codegen/pkg/securityprovider\"\n    )\n\n    func CreateSampleProviders() error {\n        // Example BasicAuth\n        // See: https://swagger.io/docs/specification/authentication/basic-authentication/\n        basicAuthProvider, basicAuthProviderErr := securityprovider.NewSecurityProviderBasicAuth(\"MY_USER\", \"MY_PASS\")\n        if basicAuthProviderErr != nil {\n            panic(basicAuthProviderErr)\n        }\n\n        // Example BearerToken\n        // See: https://swagger.io/docs/specification/authentication/bearer-authentication/\n        bearerTokenProvider, bearerTokenProviderErr := securityprovider.NewSecurityProviderBearerToken(\"MY_TOKEN\")\n        if bearerTokenProviderErr != nil {\n            panic(bearerTokenProviderErr)\n        }\n\n        // Example ApiKey provider\n        // See: https://swagger.io/docs/specification/authentication/api-keys/\n        apiKeyProvider, apiKeyProviderErr := securityprovider.NewSecurityProviderApiKey(\"query\", \"myApiKeyParam\", \"MY_API_KEY\")\n        if apiKeyProviderErr != nil {\n            panic(apiKeyProviderErr)\n        }\n\n        // Example providing your own provider using an anonymous function wrapping in the\n        // InterceptoFn adapter. The behaviour between the InterceptorFn and the Interceptor interface\n        // are the same as http.HandlerFunc and http.Handler.\n        customProvider := func(req *http.Request, ctx context.Context) error {\n            // Just log the request header, nothing else.\n            log.Println(req.Header)\n            return nil\n        }\n\n        // Exhaustive list of some defaults you can use to initialize a Client.\n        // If you need to override the underlying httpClient, you can use the option\n        //\n        // WithHTTPClient(httpClient *http.Client)\n        //\n        client, clientErr := NewClient(\"https://api.deepmap.com\", WithRequestEditorFn(apiKeyProvider.Intercept))\n\n        return nil\n    }\n```\n\n## Extensions\n\n`oapi-codegen` supports the following extended properties:\n\n- `x-go-type`: specifies Go type name. It allows you to specify the type name for a schema, and\n  will override any default value. This extended property isn't supported in all parts of\n  OpenAPI, so please refer to the spec as to where it's allowed. Swagger validation tools will\n  flag incorrect usage of this property.\n- `x-go-name`: specifies Go field name. It allows you to specify the field name for a schema, and\n  will override any default value. This extended property isn't supported in all parts of\n  OpenAPI, so please refer to the spec as to where it's allowed. Swagger validation tools will\n  flag incorrect usage of this property.\n- `x-oapi-codegen-extra-tags`: adds extra Go field tags to the generated struct field. This is\n  useful for interfacing with tag based ORM or validation libraries. The extra tags that\n  are added are in addition to the regular json tags that are generated. If you specify your \n  own `json` tag, you will override the default one. \n\n    ```yaml\n    components:\n      schemas:\n        Object:\n          properties:\n            name:\n              type: string\n              x-oapi-codegen-extra-tags:\n                tag1: value1\n                tag2: value2\n    ```\n  In the example above, field `name` will be declared as: \n  \n  ```\n  Name string `json:\"name\" tag1:\"value1\" tag2:\"value2\"`\n  ```\n- `x-go-type-import`: adds extra Go imports to your generated code. It can help you, when you want to\n   choose your own import package for `x-go-type`.\n\n  ```yaml\n    schemas:\n      Pet:\n        properties:\n          age:\n            x-go-type: myuuid.UUID\n            x-go-type-import:\n              name: myuuid\n              path: github.com/google/uuid\n  ```\n  After code generation you will get this:\n  ```go\n    import (\n        ...\n        myuuid \"github.com/google/uuid\"\n    )\n    \n  //Pet defines model for Pet.\n    type Pet struct {\n        Age *myuuid.UUID `json:\"age,omitempty\"`\n    }\n\n  ```\n  `name` is an optional parameter. Example:\n\n  ```yaml\n  components:\n  schemas:\n    Pet:\n      properties:\n        age:\n          x-go-type: uuid.UUID\n          x-go-type-import:\n            path: github.com/google/uuid\n      required:\n        - age\n  ```\n\n  After code generation you will get this result:\n\n  ```go\n  import (\n\t  \"github.com/google/uuid\"\n  )\n\n  // Pet defines model for Pet.\n  type Pet struct {\n\t  Age uuid.UUID `json:\"age\"`\n  }\n  ```\n\n\n## Using `oapi-codegen`\n\nThe default options for `oapi-codegen` will generate everything; client, server,\ntype definitions and embedded swagger spec, but you can generate subsets of\nthose via the `-generate` flag. It defaults to `types,client,server,spec`, but\nyou can specify any combination of those.\n\n- `types`: generate all type definitions for all types in the OpenAPI spec. This\n will be everything under `#components`, as well as request parameter, request\n body, and response type objects.\n- `server`: generate the Echo server boilerplate. `server` requires the types in the\n same package to compile.\n- `chi-server`: generate the Chi server boilerplate. This code is dependent on\n that produced by the `types` target.\n- `client`: generate the client boilerplate. It, too, requires the types to be\n present in its package.\n- `spec`: embed the OpenAPI spec into the generated code as a gzipped blob. This\n- `skip-fmt`: skip running `goimports` on the generated code. This is useful for debugging\n the generated file in case the spec contains weird strings.\n- `skip-prune`: skip pruning unused components from the spec prior to generating\n the code.\n- `import-mapping`: specifies a map of references external OpenAPI specs to go\n Go include paths. Please see below.\n\nSo, for example, if you would like to produce only the server code, you could\nrun `oapi-codegen -generate types,server`. You could generate `types` and\n`server` into separate files, but both are required for the server code.\n\n`oapi-codegen` can filter paths base on their tags in the openapi definition.\nUse either `-include-tags` or `-exclude-tags` followed by a comma-separated list\nof tags. For instance, to generate a server that serves all paths except those\ntagged with `auth` or `admin`, use the argument, `-exclude-tags=\"auth,admin\"`.\nTo generate a server that only handles `admin` paths, use the argument\n`-include-tags=\"admin\"`. When neither of these arguments is present, all paths\nare generated.\n\n`oapi-codegen` can filter schemas based on the option `--exclude-schemas`, which is\na comma separated list of schema names. For instance, `--exclude-schemas=Pet,NewPet`\nwill exclude from generation schemas `Pet` and `NewPet`. This allow to have a\nin the same package a manually defined structure or interface and refer to it\nin the openapi spec.\n\nSince `go generate` commands must be a single line, all the options above can make\nthem pretty unwieldy, so you can specify all of the options in a configuration\nfile via the `--config` option. Please see the test under\n[`/internal/test/externalref/`](https://github.com/deepmap/oapi-codegen/blob/master/internal/test/externalref/externalref.cfg.yaml)\nfor an example. The structure of the file is as follows:\n    \n```yaml\npackage: externalref\ngenerate:\n  models: true\n  embedded-spec: true\noutput-options:\n  skip-prune: true\nimport-mapping:\n  ./packageA/spec.yaml: github.com/deepmap/oapi-codegen/internal/test/externalref/packageA\n  ./packageB/spec.yaml: github.com/deepmap/oapi-codegen/internal/test/externalref/packageB\noutput: externalref.gen.go\noutput-options:\n  skip-prune: true\n```\n\nHave a look at [`cmd/oapi-codegen/oapi-codegen.go`](https://github.com/deepmap/oapi-codegen/blob/master/cmd/oapi-codegen/oapi-codegen.go#L48) \nto see all the fields on the configuration structure.\n\n### Import Mappings\n\nOpenAPI specifications may contain references to other OpenAPI specifications,\nand we need some additional information in order to be able to generate correct\nGo code.\n\nAn external reference looks like this:\n\n    $ref: ./some_spec.yaml#/components/schemas/Type\n\nWe assume that you have already generated the boilerplate code for `./some_spec.yaml`\nusing `oapi-codegen`, and you have a package which contains the generated code,\nlet's call it `github.com/deepmap/some-package`. You need to tell `oapi-codegen` that\n`some_spec.yaml` corresponds to this package, and you would do it by specifying\nthis command line argument:\n\n    -import-mapping=./some_spec.yaml:github.com/deepmap/some-package\n\nThis tells us that in order to resolve references generated from `some_spec.yaml` we\nneed to import `github.com/deepmap/some-package`. You may specify multiple mappings\nby comma separating them in the form `key1:value1,key2:value2`.\n\n## What's missing or incomplete\n\nThis code is still young, and not complete, since we're filling it in as we\nneed it. We've not yet implemented several things:\n\n- `patternProperties` isn't yet supported and will exit with an error. Pattern\n properties were defined in JSONSchema, and the `kin-openapi` Swagger object\n knows how to parse them, but they're not part of OpenAPI 3.0, so we've left\n them out, as support is very complicated.\n\n\n## Making changes to code generation\n\nThe code generator uses a tool to inline all the template definitions into\ncode, so that we don't have to deal with the location of the template files.\nWhen you update any of the files under the `templates/` directory, you will\nneed to regenerate the template inlines:\n\n    go generate ./pkg/codegen/templates\n\nAll this command does is inline the files ending in `.tmpl` into the specified\nGo file.\n\nAfterwards you should run `go generate ./...`, and the templates will be updated\n accordingly.\n\nAlternatively, you can provide custom templates to override built-in ones using\nthe `-templates` flag specifying a path to a directory containing templates\nfiles. These files **must** be named identically to built-in template files\n(see `pkg/codegen/templates/*.tmpl` in the source code), and will be interpreted\non-the-fly at run time. Example:\n\n    $ ls -1 my-templates/\n    client.tmpl\n    typedef.tmpl\n    $ oapi-codegen \\\n        -templates my-templates/ \\\n        -generate types,client \\\n        petstore-expanded.yaml\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fchanced%2Foapi-codegen","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fchanced%2Foapi-codegen","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fchanced%2Foapi-codegen/lists"}