6 ms·

>I agree that a streaming response is cool, but why the dismissal of returning valid JSON, streamed? JSON hasn't been designed for chunked interpretation. How

>I agree that a streaming response is cool, but why the dismissal of returning valid JSON, streamed? JSON hasn't been designed for chunked interpretation. How would the client know when to start interpreting the received message? How could you tell the difference between a valid chunk or malformed response? >With this new-line-delimited JSON format all your clients HAVE to know about your new protocol Yes. It's probably not a good option for public. It should be a complement to a more general API. I would put this in the bucket of micro-optimization for very specific use-cases. Regardless, if you publish your API and document it, other developers should be able to consume it just fine. It's not rocket science.

beau 9y ago
It works for Twitter: https://developer.twitter.com/en/docs/tutorials/consuming-streaming-data https://developer.twitter.com/en/docs/tutorials/consuming-st...
- platz 9y ago
  > carriage-return (\r\n) delimited JSON-endocded activities That's not JSON
  - Spivak 9y ago
    Why would you say that? > Insignificant whitespace is allowed before or after any of the six structural characters. Where whitespace may be space, carriage return, line feed, or horizontal tab. It's explicitly valid JSON. https://tools.ietf.org/html/rfc7159#section-2 https://tools.ietf.org/html/rfc7159#section-2
    - platz 9y ago
      ok - but my point is that it's a protocol, that is more specific than json i.e. streaming JSON in full generality has problems. if you want to restrict yourself to a subset and create a protocol, thats great - but it's not really "streaming JSON"
masklinn 9y ago
> JSON hasn't been designed for chunked interpretation. How would the client know when to start interpreting the received message? Neither has XML and yet we have plenty of working streaming XML parsers. > How could you tell the difference between a valid chunk or malformed response? Same as usual, when it breaks.

beau 9y ago

It works for Twitter: https://developer.twitter.com/en/docs/tutorials/consuming-streaming-data https://developer.twitter.com/en/docs/tutorials/consuming-st...

platz 9y ago
> carriage-return (\r\n) delimited JSON-endocded activities That's not JSON
- Spivak 9y ago
  Why would you say that? > Insignificant whitespace is allowed before or after any of the six structural characters. Where whitespace may be space, carriage return, line feed, or horizontal tab. It's explicitly valid JSON. https://tools.ietf.org/html/rfc7159#section-2 https://tools.ietf.org/html/rfc7159#section-2
  - platz 9y ago
    ok - but my point is that it's a protocol, that is more specific than json i.e. streaming JSON in full generality has problems. if you want to restrict yourself to a subset and create a protocol, thats great - but it's not really "streaming JSON"

masklinn 9y ago

> JSON hasn't been designed for chunked interpretation. How would the client know when to start interpreting the received message? Neither has XML and yet we have plenty of working streaming XML parsers. > How could you tell the difference between a valid chunk or malformed response? Same as usual, when it breaks.