Http abstraction over RPC

[XavierChanth]

Is your feature request related to a problem? Please describe.

It would be nice to have better interop with HTTP based programs, so having a wrapper around RPC which implements the HTTP interfaces in Dart would be nice to have.

Describe the solution you'd like

There are two solutions that come to mind:

1. A library which simply exposes an RPC client as an HTTP client interface, and an RPC server as an HTTP server interface. This is useful when you want a single solution that looks and feels like an HTTP server, but is not an HTTP server. I see this being used to take an existing application using HTTP and simply swap out the HTTP interface with an atPlatform RPC service. (i.e. touching as little code as possible)

2. A library which serves an HTTP server, which forwards requests over an RPC client, and an RPC server which forwards requests over an HTTP client. I see this being used to along side an existing HTTP application, and wrapping it by point the HTTP client at the atRPC's HTTP server, and then point the atRPC's HTTP client at the HTTP server. (i.e. touching no existing code, only changing routes and closing ports)

For both solutions, there is only real value if it can support at_policy natively, ideally with developer defined policy evaluation. (i.e. the application developer defines how the RPC server resolves policies, not some statically pre-defined way)

Describe alternatives you've considered

NoPorts is the only way right now, but NoPorts is incapable of applying policy evaluation to the HTTP request body, in theory this solution would be able to.

Additional context

N/A

[XavierChanth]

I've spent about an hour on option 1. It is most certainly doable, but feels like a waste of time.
A better use of time would be providing some examples of how to migrate HTTP based code to use the AtRpc interface. The Http implementation has a ton of little classes that need porting, it's not complicated work, but it would take more time than it's worth pursuing right now. Documentation and examples take less effort and produce nearly equal results in terms of developer experience. It also results in the end-developer's code being cleaner, more understandable (as they have to learn what is actually happening), with less layers of abstraction.

Still looking at option 2 as a something worth adding to the SDK.
As for how to continue with option 1, I think I'll focus on making it an example or demo in at_demos.

Edit: I just referenced this issue in a commit which has the code so you can see what I was intending to do. See below.

[XavierChanth]

This is actually quite hard to do, backlogging for now as I've found a more reasonable path forward with streams. Given that MCP supports things like stdio and sse, I've seen a ton of packages abstracting their transport over a stream interface.