ht's API is an RPC-style newline-delimited JSON sent over stdin/stdout. This reminds me strongly of varlink, an IPC standard used by systemd and podman (the docker alternative). The biggest difference is that varlink uses null-byte-delimited JSON rather than newline-delimited JSON, and usually uses Unix sockets instead of stdin/stdout (so that many clients can connect at once).
What could be gained?
Instead of maintaining a list of supported methods in project README, with "this method returns XYZ" / "this method doesn't return", you could maintain a varlink IDL file
Streaming support, so that clients don't have to poll getView
Error messages by setting the error field in reply JSON
Introspection - every varlink server has to reply to GetInfo and GetInterfaceDescription messages. This makes it easy for clients to see if a server version is new enough to support some new methods.
[!NOTE]
This is an opinionated suggestion, feel free to disregard.
ht's API is an RPC-style newline-delimited JSON sent over stdin/stdout. This reminds me strongly of varlink, an IPC standard used by systemd and podman (the docker alternative). The biggest difference is that varlink uses null-byte-delimited JSON rather than newline-delimited JSON, and usually uses Unix sockets instead of stdin/stdout (so that many clients can connect at once).What could be gained?
getViewerrorfield in reply JSONGetInfoandGetInterfaceDescriptionmessages. This makes it easy for clients to see if a server version is new enough to support some new methods.