"It kind of breaks the Unix/Linux piping paradigm using these streams for bidirectional communication."
Uhm ... no? They were meant for that.
But the rest of the critique is well founded. "Streamable HTTP" is quite an amateurish move.
No they weren't. If we look at it from the perspective of pipelines (and not interactive programs that take input directly from the user and display output on the screen), stdin is for receiving data from the program in the pipeline before you, and stdout is for sending data to the thing in the pipeline after you. That's not bidirectional, that's a unidirectional flow.
STDIN means Standard INPUT.
STDOUT means Standard OUTPUT.
There is no design/hardware/software limitation to reading and writing to them at the same time. That's your bidirectional channel with that one process.
>stdin is for receiving data from the program in the pipeline before you, and stdout is for sending data to the thing in the pipeline after you
Yes, and you took that from my comment here: https://news.ycombinator.com/item?id=43947777
Did you just wanted to ratify my argument, or is there something else you want to add?
But it's more like an HTTP API, writing or requesting some data, getting a response, doing something else with that, etc. - whereas typically with stdin/stdout you're doing something more like `generate-data | transform | transform2 | store`, manipulating an initial input, not decision-making and providing more input based on the output of early input. Not to say you can't, but it does seem a bit weird to me too.
(To be fair I suppose a shell is an obvious counter-example. Or anything that launches an interactive prompt or interpreter.)