RFC: first-class response objects

[bf4]

Is your feature request related to a problem? Please describe.

Right now the gem returns raw HTTParty response objects which requires are certain amount of processing, especially on success, since the response may be successful but have an error-like response like "please retry with smaller completion length or fewer completions". Having an (opt-in) first-class response-object in the gem would solve the processing problem for all users of the gem. I'd be happy to make this contribution.

This would also make it easier to change the underlying gem from HTTParty to something else without affecting end-users.

Describe the solution you'd like

e.g. Response.from(http_response) would be an object which responds to success? but also has more information about specific response details such as choices and soft-errors like "please retry with smaller completion length or fewer completions".

Describe alternatives you've considered

Right now we do this work in our app.

Additional context

Let me know if I missed anything. I'd be happy to work on this, as an opt-in feature so that it doesn't break existing releases.

[alexrudall]

Definitely open to this. I want to move away from HTTParty in the next major release anyway to something faster and which supports streaming, maybe Typhoeus, so this could be helpful with that. Appreciate your work on this and happy to review any PR

[bf4]

I'd personally prefer not to rely on Typhoeus either. It's a fine gem, but using Faraday would at least give people the choice of adapter.

[alexrudall]

@bf4 definitely open to looking at that - are you still interested in adding your Response object PR?

[bf4]

@alexrudall Yes. I'm exploring the shape of our usage of the gem right now, both on success and error. My general idea is something kind of like what httparty does but more specific to the ApI

• success?
• code
• raw_response_body
• parsed_response_body <-- this is where we start to get value by having the gem, which knows how to interpret the response data, to just return e.g. 'choices', or e.g. some special parsing of the various error cases, etc.

[alexrudall]

Hmm ok cool, thanks for this. How would streaming work?

[alexrudall]

@bf4 would love a PR on this if you have time! Even just a minimum proof of concept.

[bf4]

@alexrudall will do. I've been thinking about what's the minimum change to add a consistent interface. Thanks for checking in.

[bf4]

Will be taking advantage of general lessons learned using it, while maintaining current functionality, but also I found there's an OAS (OpenAPI) spec https://github.com/openai/openai-openapi which they used to generate the Node.js implementation https://github.com/openai/openai-node (the reference python library seems to be hand-crafted https://github.com/openai/openai-python ). Fun!

[bf4]

pushed a thing

[bf4]

Closing due to lack of maintainer interest to move forward.