A few of our APIs are streaming, in that they produce long-lived HTTP responses containing newline-delimited JSON of arbitrary length. When these APIs encounter an error mid-stream, they end the response and write HTTP trailers containing error information.
Thing is, no browsers support HTTP trailers so the browser experience is to end the stream (pull stream, readable stream, etc) with no error message.
It seem there's no plan to add HTTP trailers to the fetch API either, so we need a better way of handling errors. In fact the whole API needs overhauling to be leaner, more consistent and less tied to golang conventions. I did a bunch of work on a RESTful HTTP server for IPFS a while ago, though TBF it could use bringing in line with ipfsx.
Errors though, we could:
- Deprecate the HTTP API and implement RPC over websockets - this would also allow us to do realtime events
- ✅ Fast (to use)
- ✅ Simple mapping from existing API
- ❌ Big job, incredibly disruptive
- Chunk streaming responses into multipart messages (e.g. instead of each stream entity being delimited by
\n it would be a full-blown message part with appropriate mime-type headers, etc which would let us know if we are about to parse an error or not)
- ✅ Uses existing web conventions
- ❌ Adds overhead for small payloads
- Return a unique identifier with each response and allow the client to use that id to look up an error for a limited time via an error endpoint
- Just write the error into the response body and hope the client notices
- ❌ Unsuspecting clients likely to encounter significant surprise
My preference would be for 2, though preferably as part of a wider rethink of the API, a la ipfsx.
A few of our APIs are streaming, in that they produce long-lived HTTP responses containing newline-delimited JSON of arbitrary length. When these APIs encounter an error mid-stream, they end the response and write HTTP trailers containing error information.
Thing is, no browsers support HTTP trailers so the browser experience is to end the stream (pull stream, readable stream, etc) with no error message.
It seem there's no plan to add HTTP trailers to the fetch API either, so we need a better way of handling errors. In fact the whole API needs overhauling to be leaner, more consistent and less tied to golang conventions. I did a bunch of work on a RESTful HTTP server for IPFS a while ago, though TBF it could use bringing in line with ipfsx.
Errors though, we could:
\nit would be a full-blown message part with appropriate mime-type headers, etc which would let us know if we are about to parse an error or not)My preference would be for 2, though preferably as part of a wider rethink of the API, a la ipfsx.