Client generation

Example for dynamic client?

Use-case: I have the swagger spec file for an existing 3rd party REST service for their application. A dynamic client would allow me to load the swagger spec file and provide the ability to formulate requests and parse responses based on the loaded spec file.

For e.g. there are REST client packages for go, like go-resty, that provide a nice interface to interact with a REST server, but go-resty doesn't understand swagger specs.

  • Just like the untyped dynamic server example in go-swagger, is there an example for a dynamic client?
  • Can a REST client be created at runtime by loading a swagger spec file, without going through a code generation and compilation?
  • Can I get the REST client functionality without first generating a client using go-swagger and then compiling it back into the code.
  • Can this be done dynamically like the dynamic server example?

Answer: you can't currently.

You'd have to do by hand everything the code generator does for you. Every time the API changes, you would have to do this again. The use case for the server side is covered but not the client side.

That being said, you might find this test useful as an example: runtime test

Originally from issue #996.

Can we set a User-Agent header?

Use-Case: we would like to be able to set an arbitrary user-agent header either at client generation time or at compile time.

Is it possible to do this?

The Swagger specification is irrelevant in this case because we are using the same specification to generate many clients.

Answer: here is the outline of how to achieve that.

var myRoundTripper http.RoundTripper = createRoundTripper()
transport := httptransport.New(cfg.Host, cfg.BasePath, cfg.Schemes)
transport.Transport = myRoundTripper
todoListClient := New(transport, nil)

Other use-Case: can the same pattern of using an http.RoundTripper be used to implement the AWS Signature v4 which requires reading and modifying the *http.Request before its sent?

Answer: yes it can.

The roundtripper is the last thing executed before sending the request on the wire.

See also issue #935.

Originally from issue #911.

Back to all contributions

results matching ""

    No results matching ""