Choose Between REST, WebSocket, and Server-Sent Events for an Agent Runtime

An agent runtime accepts jobs, streams progress, and returns a final result. Compare ordinary HTTP request-response, Server-Sent Events, and WebSocket. Recommend a protocol shape for job submission, cancellation, progress, reconnects, and final delivery. ### Constraints & Assumptions - Some jobs finish quickly while others take minutes. - Clients may disconnect and later reconnect. - The runtime may be deployed behind common HTTP load balancers and gateways. - Do not assume bidirectional low-latency traffic is always required. ### Clarifying Questions to Ask - Must users send interactive commands after a job starts? - Can progress events be replayed from a durable job log? - Which clients and intermediaries must be supported? ### What a Strong Answer Covers - A requirement-based comparison of directionality, connection lifetime, reconnect behavior, backpressure, and infrastructure support. - A durable asynchronous job resource rather than tying correctness to one connection. - Idempotent submission, cancellation races, progress sequence IDs, and result retrieval. - A justified choice, such as HTTP submission plus SSE for one-way progress, with conditions that would require WebSocket. - Authentication renewal, resource limits, observability, and fallback behavior. ### Follow-up Questions - How would a client resume without duplicating progress events? - What changes if the agent needs frequent human approvals mid-run? - How would you protect the service from clients that read a stream too slowly?