-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
My api result is an array with the response broken up over multiple candidates #5
Comments
Hey @joshdaloewen, thanks for opening an issue.
May you please share your cURL command? By running the code you shared, here's the underlying cURL equivalent generated by the Gem: curl --request POST \
--url https://generativelanguage.googleapis.com/v1/models/gemini-pro:streamGenerateContent?key=$GEMINI_API_KEY \
--header 'Content-Type: application/json' \
--data '{
"contents": {
"role": "user",
"parts": {
"text": "Write an essay on the history of Canada."
}
}
}' |
I figured it out, but I'm not sure how you'd want to handle it. The problem is that
uses the endpoint "streamGenerateContent" regardless of whether In my mind, the refactor that would be the most intuitive for users would be to:
All that being said, you could also allow |
Got it. I infer that I would be inclined to distinguish between the concept of an HTTP request that creates a stream to receive server-sent events and the concept of streaming related to the expected behavior and output format of the endpoints. Why? We have a lot of possible endpoints in the API:
All of them may support "streaming" (Server-Sent Events) or not. I would prefer to keep the names of the methods faithful to the original names of the raw cURL API:
Allowing any of them to be accessed through a standard HTTP request or by enabling server-sent events. Perhaps the refactoring needed to eliminate ambiguity and confusion for users would be renaming client = Gemini.new(
credentials: { ... },
options: { model: 'gemini-pro', server_sent_events: true }
)
client.stream_generate_content(
{ contents: { role: 'user', parts: { text: 'hi!' } } },
server_sent_events: true
) do |event, parsed, raw|
puts event
end
result = client.stream_generate_content(
{ contents: { role: 'user', parts: { text: 'hi!' } } },
server_sent_events: false
)
result = client.generate_content(
{ contents: { role: 'user', parts: { text: 'hi!' } } },
)
client.generate_content(
{ contents: { role: 'user', parts: { text: 'hi!' } } },
server_sent_events: true
) do |event, parsed, raw|
puts event
end Does that make sense? |
Yeah I'm liking that, and I also strongly agree that keeping the method names the same as the raw API urls will be most intuitive moving forward. |
I'm wondering if I'm missing a configuration. My response is broken up into numerous parts. I know I could combine them, but I'm wondering why this result is different than what I get when I run a curl command to hit the API.
I run this:
and I get this response:
The text was updated successfully, but these errors were encountered: