Difference between APPLICATION_STREAM_JSON_VALUE and APPLICATION_NDJSON_VALUE

Question

While working with Spring 5 reactive APIs , i came across the deprecated MediaType APPLICATION_STREAM_JSON_VALUE , which when used display values from a GET REST endpoint in a stream kind of fashion , that is showing up values as they appear on the browser . But as of today the documentation states that it has been replaced by APPLICATION_NDJSON_VALUE as per below text from the documentation :

APPLICATION_STREAM_JSON_VALUE Deprecated. as of 5.3 since it originates from the W3C Activity Streams specification which has a more specific purpose and has been since replaced with a different mime type. Use APPLICATION_NDJSON as a replacement or any other line-delimited JSON format (e.g. JSON Lines, JSON Text Sequences).

When i checked the behaviour of the MediaType APPLICATION_NDJSON_VALUE , i observe that when a GET API is consumed on the browser , instead of streaming it on browser real time , results get downloaded as file , which you can later view . But does that in any way impact the streaming behaviour or is it exactly the same ? Does APPLICATION_NDJSON_VALUE brings in some other significance as well or its just a pure replacement for APPLICATION_STREAM_JSON_VALUE . And if it is just a replacement , why the browser streaming behaviour changes to being results of a Flux getting downloaded ? Or let me know if i am doing any mistake while trying to replicate the exact behaviour ?

Answer 1

But does that in any way impact the streaming behaviour or is it exactly the same?

It's exactly the same. The content type header is only telling the client what type of content it's serving, nothing more. The browser will do its best to look at that header and work out whether to display something inline or download it, but it's just a "best guess", especially in the case of reasonably new standards like newline delimited JSON. In practice you're never going to be opening this in a browser anyway (instead consuming it as an API), so it's not really that big a deal.

If you really need it not to download in the browser, you can try adding a Content-Disposition: inline header - but personally I'd just ignore the browser's behaviour and consume it with a tool more suited to the job (like curl for instance) instead.