update: headers info with functions (Chat + Audio + Completion)

[Krobys]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Related Issue	Fix #206

Describe your change

Added two new methods to Chat and Audio, so now two new functions available for getting response with headers. Also updated sample to test new features

What problem is this fixing?

No headers info was available with default response

[aallam]

Hello @Krobys, thank you so much for your valuable contribution!

I appreciate your idea, and I think we should adopt the following structure:

package com.aallam.openai.api.core

data class OpenAIResponse<T>(val headers: Map<String, List<String>>, val body: T)

This serves two main purposes:

• Enhancement Capability: This design would allow us to extend the class with additional methods or getter helpers for accessing specific fields in the headers, improving the usability of the API.

• Encapsulation: It would also help us keep the implementation details hidden by not exposing Ktor classes in the public API. They would remain purely as implementation detail.

Regarding the method naming, I suggest we use the prefix create (e.g. createCompletion). This would align our naming conventions with those used by official clients, providing a consistent experience.

Once again, thank you for your insights and contributions. They are greatly appreciated!

[Krobys]

Hello @Krobys, thank you so much for your valuable contribution!

I appreciate your idea, and I think we should adopt the following structure:

package com.aallam.openai.api.core

data class OpenAIResponse<T>(val headers: Map<String, List<String>>, val body: T)

This serves two main purposes:

• Enhancement Capability: This design would allow us to extend the class with additional methods or getter helpers for accessing specific fields in the headers, improving the usability of the API.
• Encapsulation: It would also help us keep the implementation details hidden by not exposing Ktor classes in the public API. They would remain purely as implementation detail.

Regarding the method naming, I suggest we use the prefix create (e.g. createCompletion). This would align our naming conventions with those used by official clients, providing a consistent experience.

Once again, thank you for your insights and contributions. They are greatly appreciated!

is it worth changing the old methods to return a new object or adding paired similar methods methods as I did and not touching the old ones for compatibility

[aallam]

is it worth changing the old methods to return a new object or adding paired similar methods methods as I did and not touching the old ones for compatibility

You're correct, changing the old methods would introduce a breaking change. We would need to wait for a major release to implement that. In the meantime, adding new methods, as you've done, should suffice and maintain compatibility.