Add support for httpx and async transport

[chalmerlowe]

Add support for httpx for async transport. An exemplar PR to support this is available (it is currently closed to enable migration to the Python mono-repo).

Both aiohttp and httpx are powerful libraries for making asynchronous HTTP requests in Python, but they serve slightly different purposes and have different design philosophies.

Here is a breakdown of their differences, pros, cons, and when to use each, as provided by Gemini AI.

---

1. High-Level Overview

• aiohttp: The "venerable" choice. It has been the industry standard for asynchronous HTTP in Python for years. It is a full-featured networking library that provides both a Client and a Server framework.
• httpx: The "modern" choice. It was designed to be the spiritual successor to the famous requests library, but built for the modern asyncio era. Its biggest selling point is that it supports both Synchronous and Asynchronous APIs and has built-in support for HTTP/2.

---

2. Key Differences

Feature	aiohttp	httpx
Sync Support	No (Async only)	Yes (Sync and Async)
API Style	Unique, explicit (requires ClientSession)	Very similar to requests
HTTP/2 Support	No (supports HTTP/1.1 only)	Yes (Optional)
Web Server	Yes (Built-in)	No (Client only)
Type Hinting	Good	Excellent (Fully type-annotated)
Cookie/Session	Strictly via ClientSession	Flexible (Top-level or Client)

---

3. aiohttp

Pros:

• Performance: Generally considered slightly faster and more efficient in high-concurrency benchmarks because it is highly optimized for asyncio.
• Maturity: It is battle-tested and has been used in production by major companies for nearly a decade.
• All-in-one: If you are building a web server and also need to make outgoing requests, you only need one library.
• Control: Offers lower-level control over connections and TCP parameters.

Cons:

• Async-Only: You cannot use it in a synchronous script. This makes it difficult to share code between sync and async parts of a codebase.
• Boilerplate: It is more verbose. You must use a ClientSession context manager for almost everything.
• No HTTP/2: It currently does not support HTTP/2 for its client.

---

4. httpx

Pros:

• The "Requests" Feel: If you know how to use requests, you know how to use httpx. The transition is almost seamless.
• Sync & Async: You can use httpx.get() for a quick script and await client.get() for an async app. This allows library authors to support both paradigms easily.
• HTTP/2 Support: This is a major advantage for modern web scraping and communicating with APIs that prioritize HTTP/2.
• Strictness: It has better defaults for things like timeouts (it enforces them by default, whereas aiohttp often doesn't).
• WSGI/ASGI Support: You can call your FastAPI or Flask app directly through httpx for testing without needing a running server.

Cons:

• Performance: In some raw benchmarks, it is slightly slower than aiohttp (though this is rarely the bottleneck in real-world IO-bound applications).
• Client Only: It does not include a web server framework.

---

5. Code Comparison

aiohttp (Async only):

import aiohttp
import asyncio

async def main():
    async with aiohttp.ClientSession() as session:
        async with session.get('https://example.com') as response:
            print(response.status)
            print(await response.text())

asyncio.run(main())

httpx (Async):

import httpx
import asyncio

async def main():
    async with httpx.AsyncClient() as client:
        response = await client.get('https://example.com')
        print(response.status_code)
        print(response.text)

asyncio.run(main())

---

6. When to use which?

Use httpx if:

1. You want the best developer experience: The API is cleaner and more intuitive.
2. You need HTTP/2: This is a non-negotiable requirement for some modern APIs.
3. You are migrating from requests: It will be much easier to port your code.
4. You need both Sync and Async: If you are writing a library or a CLI tool that needs to support both modes.
5. You are using FastAPI: httpx is the standard recommendation for testing and making external calls within FastAPI.

Use aiohttp if:

1. You are building a high-performance web server: Using aiohttp as both the server and client keeps your stack unified.
2. Raw speed is the Internal transport discussion #1 priority: If you are making millions of requests and every millisecond of overhead matters.
3. Legacy codebases: If you are working on an existing project that already uses aiohttp, there is rarely a compelling reason to switch.
4. Complex TCP/Networking requirements: If you need deep control over the underlying transport layer.

Summary

For 90% of new projects, httpx is the recommended choice because of its flexibility, HTTP/2 support, and modern API. Use aiohttp only if you need its server-side capabilities or are working in a performance-critical, async-only environment where every drop of optimization counts.