Package net.thevpc.naru.ext.models.gemini

Class NaruGeminiNativeRequestSerializer

java.lang.Object
net.thevpc.naru.ext.models.gemini.NaruGeminiNativeRequestSerializer
All Implemented Interfaces:
NaruCacheAwareRequestSerializer, NaruModelRequestSerializer
public class NaruGeminiNativeRequestSerializer extends Object implements NaruCacheAwareRequestSerializer
Serializes a NaruModelRequest into the native Gemini generateContent wire format. 
 POST {base}/v1beta/models/{model}:generateContent
 {
   "systemInstruction": {"role": "system", "parts": [{"text": "..."}]},
   "contents": [
     {"role": "user",      "parts": [{"text": "..."}]},
     {"role": "model",     "parts": [{"text": "..."}, {"functionCall": {...}}]},
     {"role": "user",      "parts": [{"functionResponse": {...}}]}
   ],
   "tools": [{"functionDeclarations": [{"name":"...","description":"...","parameters":{...}}]}],
   "generationConfig": {"temperature":..., "topP":..., "maxOutputTokens":...,
                        "stopSequences":[...]}
 }

Native Gemini differs from every other protocol NARU speaks in three ways that matter here:

  • There is no system role inside contents; system material goes in the separate top-level systemInstruction.
  • Assistant is called model, not assistant.
  • Tool definitions are grouped in a single tools[] entry holding a list, rather than one entry per tool.

Function calling is still two half-messages rather than one message with both directions: the model's functionCall parts and the following user's functionResponse parts are separate contents entries, which is also how the wire protocol models a tool round trip.