Consider unifying public HTTP API surfaces on camelCase

[cgillum]

Summary

Evaluate standardizing the public HTTP APIs in the .NET and Python Azure Functions hosts on camelCase. This would improve coherence across agent and workflow endpoints and align the extension with Azure/Durable Functions conventions.

This was identified while implementing synchronous workflow invocation in #25. The current convention is internally consistent per surface, but not consistent across the complete HTTP API.

Current state

Entity type	Surface	Location	Current convention and examples
Agents	query parameters	.NET and Python	snake_case: session_id, wait_for_response
Agents	request bodies	.NET and Python	snake_case: session_id; Python also accepts body-level wait_for_response
Agents	response bodies	.NET and Python	snake_case: session_id, correlation_id
Workflows	query parameters	.NET and Python	camelCase: runId, waitForResponse, timeoutSeconds
Workflows	request bodies	.NET and Python	camelCase: eventName, response
Workflows	response bodies	.NET and Python	camelCase, though equivalent fields are not always named identically: runId/instanceId, workflowStatus/runtimeStatus, result/output, statusQueryGetUri, respondUri
Workflows	route parameters	.NET and Python	camelCase: {runId}, {instanceId}, {requestId}
Agents	MCP tool arguments	Existing agent tools	camelCase, including sessionId

Potential camelCase impact

The casing migration would primarily affect Agents in both the .NET and Python hosts. The Workflows HTTP surface and agent MCP tool arguments already use camelCase and would not require casing-only changes.

Entity type	Surface	Languages	Potential changes
Agents	query parameters	.NET and Python	session_id → sessionId; wait_for_response → waitForResponse; thread_id → threadId if the deprecated alias still exists when this work is done
Agents	request bodies	.NET and Python	session_id → sessionId; thread_id → threadId if the deprecated alias still exists
Agents	request bodies	Python only	Body-level wait_for_response → waitForResponse, or remove this Python-only input path as part of contract alignment
Agents	response bodies	.NET and Python	session_id → sessionId; correlation_id → correlationId
Agents	MCP tool arguments	Existing agent tools	No casing change; sessionId is already camelCase
Workflows	query, route, request, and response surfaces	.NET and Python	No casing change; these surfaces already use camelCase

Fields such as message, status, and response would be unchanged.

Additional coherence questions

A casing migration is an opportunity to decide whether closely related cross-language differences should be normalized in the same effort or tracked separately:

• Singular versus plural workflow routes (workflow versus workflows)
• runId versus instanceId for the same workflow identity concept
• Plain-text versus JSON asynchronous-start responses
• HTTP 200 versus HTTP 500 for synchronous workflow failures
• workflowStatus/result versus runtimeStatus/output
• Python-only support for wait_for_response in the request body

These are broader than casing and should not be changed implicitly, but they affect the scope of a fully coherent public contract.

Compatibility considerations

Changing agent query parameters and JSON properties would be a breaking HTTP contract change. Before implementation, decide whether to:

• Make a hard rename in a planned breaking release
• Temporarily accept both names while emitting only camelCase
• Version the affected endpoints

The deprecated thread_id alias should also be coordinated with its planned removal so the migration does not introduce unnecessary compatibility paths.

Proposed completion criteria

• Inventory every public query parameter, route parameter, request property, and response property in both hosts.
• Define one canonical camelCase name for each shared concept.
• Ensure equivalent .NET and Python endpoints use the same names and casing.
• Document the compatibility and versioning strategy explicitly.
• Update implementation, tests, samples, API documentation, and changelogs together.
• Add contract tests that prevent casing or naming drift between surfaces and languages.