Something like this?

 class Builder {
 private var apiKey: String = ""
 private var organization: String? = null
 private var client: OkHttpClient = OkHttpClient()
 private var azureBaseUrl: String = ""
 private var apiVersion: String = "2023-03-15-preview"
 private var modelName: String = ""
 fun apiKey(apiKey: String) = apply { this.apiKey = apiKey }
 fun organization(organization: String?) = apply { this.organization = organization }
 fun client(client: OkHttpClient) = apply { this.client = client }
 fun azureBaseUrl(azureBaseUrl: String) = apply { this.azureBaseUrl = azureBaseUrl }
 fun apiVersion(apiVersion: String) = apply { this.apiVersion = apiVersion }
 fun modelName(modelName: String) = apply { this.modelName = modelName }
 fun build(): AzureOpenAI {
 return AzureOpenAI(
 apiKey = apiKey,
 organization = organization,
 client = client,
 azureBaseUrl = azureBaseUrl,
 apiVersion = apiVersion,
 modelName = modelName
 )
 }
 }

That's the idea but instead of having a seperate AzureOpenAI, we just change the existing OpenAI class to allow custom endpoints. Then the builder class could have a method like:

fun azure(baseUrl: String, apiVersion: String, modelName: String) = apply { 
 this.endpoint = "$baseUrl/openai/deployments/$modelName/$endpoint?api-version=$apiVersion" 
}

So the build() function will always build an instance of OpenAI, even when azure is used.

I don't quite agree. We should separate concerns as stated in SOLID principles.

OpenAI API and Azure OpenAI API are two different concepts and may even diverge in the future. What we could is to create an interface with two different implementation for OpenAI API and Azure OpenAI API. This would allow the users to more easily create even their own implementations.

Alright we'll leave it to the developers to handle swapping between OpenAI and AzureOpenAI, should they choose to.

Yes, it would be like having a Connection object for the database which could switch the backing databases on the fly. For example the developer could switch from PostreSQL to a MySQL. It would be prone to bugs.
Can we proceed with the merge than? :)

Yessir, I'll merge now, then write documentation later.

1.3.1 should be live on maven central soon, I'll double check in the morning. Added a quick note in the wiki as well about Azure support. Thankyou for contributing!

That's great news, thanks! I will be probably submitting more Pull Requests, as I am currently working on a project using your OpenAI implementation... :)

Thank you for supporting the Azure API. I'm having some trouble using it, as it seems that the final URL is incorrect. According to the Azure documentation, the endpoint doesn't have a 'v1' prefix, which is different from the OpenAI API.

Here are the correct endpoints for each API:

Azure API: https://{your-resource-name}.openai.azure.com/openai/deployments/{deployment-id}/chat/completions?api-version={api-version}
OpenAI API: https://api.openai.com/v1/chat/completions
In the current code, both OpenAI and AzureOpenAI use the same endpoint with the 'v1' prefix:

const val COMPLETIONS_ENDPOINT = "v1/completions"
const val CHAT_ENDPOINT = "v1/chat/completions"
const val IMAGE_CREATE_ENDPOINT = "v1/images/generations"
const val IMAGE_EDIT_ENDPOINT = "v1/images/edits"
const val IMAGE_VARIATION_ENDPOINT = "v1/images/variations"

When I ran it in my project, I got a 404 error. All of the other parameters passed to AzureOpenAI are correct, so the 'v1' prefix might be causing the issue. Could you please check this? Thank you.

@warmwind Hi, I will go through your remarks and let you know how we can approach this issue.

@warmwind You are right, I will fix it ASAP and create a Pull request

@ugwun Thanks for your quick response. I am really looking forward to it. :D

@warmwind this is a quickfix pullrequest: #23