docs: add details on low-level api functions and overrides

docs/GENERATING-A-NEW-SDK.md

@@ -1,11 +1,3 @@
-# Generating a new SDK for OpenFGA
-
-Thanks for your interest in generating a new SDK for the [OpenFGA](https://openfga.dev)
-project.
-
-> Note: A common `camelCase` and `PascalCase` style is used for identifiers throughout
-> this document. SDKs should use identifier conventions from their language, and convert
-> these as necessary. For example, `apiUrl` will be `api_url` in Python.
 
 ## Table of Contents
 
@@ -350,13 +342,46 @@ ClientCredentials should be only static data, and will not be concerned with per
 calls or retrieving an access token. ClientCredentials will be resolved as part of
 [Authentication](#authentication).
 
-### Function signature format
+### Function signatures
 
-TODO: Expected low-level client function signatures. Mention storeId first (where applicable), then params, then configurations
+Functions of the low-level client should:
+
+* Take as input a String `storeId`
+  * `CreateStore` and `ListStores` are the only operations that do not take/require a `storeId`
+  * The `storeId` should be validated as a non-null, non-blank String
+* If applicable for the operation, take as input a modeled request `body`
+  * For example, `Check` should take a `CheckRequest` as its request `body`
+  * The `body` should at minimum be validated as non-null
+* If it is a paginated operation, it should take as optional inputs an Integer `pageSize`
+  and a String `continuationToken`
+* Take as an optional input a [`ConfigurationOverride`](#per-request-override)
+* Produce as output a promise/future that will complete with:
+  * HTTP response details. This includes the status code, headers, and raw response body
+  * If applicable for the operation, a modeled request response
 
 ### Per-request override
 
-TODO
+The low-level client should allow an optional `ConfigurationOverride` as input for each of its
+operations. The `ConfigurationOverride` should have the same properties as [`Configuration`](#configuration-1) with one exception:
+
+* Instead of `defaultHeaders`, the override should have an `additionalHeaders` of the same type
+
+When resolving the client's [`Configuration`](#configuration-1) with `ConfigurationOverride`,
+do not modify either the `Configuration` or the `ConfigurationOverride`. If necessary, construct
+a new intermediate `Configuration` for the context of an operation.
+
+The resolved configuration values should follow these rules:
+
+1. For all non-header properties, if a `ConfigurationOverride` property is set, that is the resolved value.
+   Otherwise the resolved value will be identical to the `Configuration` property.
+2. Headers are merged with the following rules:
+   1. If a header is set in `ConfigurationOverride`, it should be resolved as this header and take
+      precedence over a value set in the `Configuration`
+   2. If a header is explicitly set to a null value (null, nil, None, etc) then it should be resolved
+      as an un-set header, even if `Configuration` has the header
+   3. Any other headers from `Configuration` should be preserved
+   4. The `defaultHeaders` of the `Configuration` should be unmodified during resolution
+   5. The `additionalHeaders` of the `ConfigurationOverride` should be unmodified during resolution
 
 ## High-level client