[Interoperability] Notes on architecture

[Mec-iS]

I start collecting in this issue some material about content for the architectural-infrastructural section of the Interoperability Report. I am going to add resources as I find them. Please add a comment with relevant resources with suggestions.

This post is interesting as a starter; from practical considerations on using HTTP+SSE in some basic scenarios like using a pub-sub with multiple server processes downstream that notify via SSE multiple clients. It highlights some points that I report here:

• Compression: SSE streams are text-based, so you can (and should) enable gzip/deflate compression on your HTTP response. HTTP payload compression is well established and comes out-of-the-box compared to other optimisations like for example gRPC.
• Minimal Data: SSE messages shall be small. Only send the data the client needs. Since each event uses one HTTP packet over TCP, minimizing payload improves throughput.
• Batching Events: If events occur rapidly, multiple data items shall be batched into a single SSE event to reduce overhead (each event has some framing bytes).
• Buffering: Many reverse proxies (nginx, UWSGI) buffer responses by default, which defeats streaming. Disable buffering for SSE endpoints. For example, send the header X-Accel-Buffering: no (nginx) or configure proxy_buffering off. This ensures each yield is flushed to the client immediately.
• Garbage collection: close SSE connections on the client side when they are no longer in use (to free server resources).
• Connections limits (HTTP/1.1 vs HTTP/2): In HTTP/1.1, browsers typically allow only ~6 concurrent connections per origin. If your app must serve many SSE clients, use HTTP/2. With HTTP/2, a single TCP connection can multiplex dozens or hundreds of streams. Deploying your app on a server (or proxy) that supports HTTP/2 will greatly increase scalability.

In general, the great advantage of using HTTP is the standard in its entirety but in particular the possibility of using its widely recognised semantics and conventions, for example verbs (GET, POST, ...) one of the points that makes REST so intuitive to use.
There are also features that are under-utilised like for example HTTP-Range that in my opinion could be leveraged in defining procedures to build specialised contexts from chunks retrieved from multiple other contexts. Defining a standard based on a substrate that is not HTTP is probably deemed to not reach wide adoption as it will be prone to non-standard adaption and incompatible dialects for each implementation.
Also attention should be put in following adoption for HTTP/2 and HTTP/3 in applications, as they look much less accepted than HTTP/1.1 with its later additions; this may suggest that the future relevance of /2 and /3 may be decided by the adoption in future AI applications or not depending on the fitness of their features to agents' established workflows.

[andreiciortea]

Thanks @Mec-iS for the input. Support for asynchronous interaction is a key requirement for agents on the Web — one that goes beyond REST and the classical Web model. To add a few more resources to the list:

In addition to HTTP+SSE (used in MCP and A2A), other options include W3C WebSub, WebSocket subprotocols, etc. (cf. comparison table in Section 3.2).

Some interesting papers to consider for the conceptual part:

• Rohit Khare and Richard Taylor (2004), Extending the Representational State Transfer (REST) architectural style for decentralized systems: https://ieeexplore.ieee.org/abstract/document/1317465
  • defines Asynchronous REST among other extensions to REST (part of ARRESTED); a similar approach is implemented in CoAP via the Observe flag [RFC7252]
• Roy Fielding et al. (2017), Reflections on REST: https://dl.acm.org/doi/abs/10.1145/3106237.3121282

One more thought: I see all the benefits of using HTTP as the backbone. Going further, approaches like the one taken by the W3C Web of Things of using hypermedia controls with bindings to different protocols (even non-Web protocols) seem like an interesting way forward.