Add openAPI client generation - #71
Open
davidn wants to merge 9 commits into
Open
Conversation
client.go.tpl and the changes to output/openapi.go in this commit are largely made by an LLM. I added example cases and have closely reviewed the outputted client code. I therefore vouch more for the quality of output than quality of code. This commit is a WIP, I want to do the following: 1. reduce changes to openapi.go 2. Add more helpers to iken and use those in the client
This commit changes the generated client library to use a (not yet merged) iken change that adds an standard error and several auth types akin to those used in handler.go.tpl. This has the effect of: 1) Allowing clients to use a single error.As that works across any client. 2) Allowing clients to pass a user object in the API methods, with helpers that translate the user object into the actual wire credential. This matches the handler.go.tpl style. See https://gist.github.com/davidn/8b5ed70a4704e1dcb0f9c63159632ef8 for an example of how this gets used.
Motivation: OpenAPI operations may specify several security requirements, each of which consists of several security schemas. A invocation must fulfil all the security schemas of at least one security requirement. In addition, it's not possible to have a "no op" authenticator as even a empty token/cookie/user/pass would get encoded into the request. Faced with having to explicitly handle authenticators not being able to add auth to a request, we choose to fully respect the spec's hierachy of security groups. Change: Using `iken/httputil.ClientSecurityGroups`, requests for operations with more than one security requirement will now be authorized according to the first security requirement that has all of it's security schemas' authorizers run without error. If no security requirement can be met, the request will not be sent and an error will be returned.
davidn
marked this pull request as draft
July 10, 2026 20:24
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #71 +/- ##
=======================================
Coverage ? 30.41%
=======================================
Files ? 45
Lines ? 2591
Branches ? 0
=======================================
Hits ? 788
Misses ? 1794
Partials ? 9 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
davidn
marked this pull request as ready for review
July 16, 2026 16:39
We may often want multiple clients in the same module, so this PR allows the generated client to have a prefix on the types. This commit also adds an interface, allowing easier mocking.
Some openapi specs use x-go-type, referring to types defined in the server. We don't want these when generating clients, so add a param to ignore them. This is true by default in the openAPIClient process
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motiation: writing HTTP clients from an openapi spec is tedious and mechanistic, especially when this effort is being repeated for multiple callers of an API. While other code generators exist, they do not follow the idiomatic style of foji and its users.
What this PR does: Adds a template to generate a HTTP client library with the following characteristics (aiming to mirror handler.go.tpl):
NewClientmethod that takes in authentication functions, akin toRegisterHTTP. The actual authentication functions are a mirror of those used in the handler: they take a user object and return the require token/username/password/cookie etc.Note, the client template in this PR is LLM-generated. I guided it by closely specifying and reviewing the client code it outputted.
For an example of how code can use these generated clients, see https://gist.github.com/davidn/8b5ed70a4704e1dcb0f9c63159632ef8