Skip to content

Commit d16a710

Browse files
committed
Polish WebFlux codecs section in the docs
1 parent 4d24503 commit d16a710

File tree

1 file changed

+29
-32
lines changed

1 file changed

+29
-32
lines changed

src/docs/asciidoc/web/webflux.adoc

Lines changed: 29 additions & 32 deletions
Original file line numberDiff line numberDiff line change
@@ -673,48 +673,45 @@ readers and writers for form data, multipart requests, and server-sent events.
673673
[[webflux-codecs-jackson]]
674674
==== Jackson JSON
675675

676-
The decoder relies on Jackson's non-blocking, byte-array parser to parse a stream of byte
677-
chunks into a `TokenBuffer` stream, which can then be turned into objects with Jackson's
678-
`ObjectMapper`. The JSON and https://github.com/FasterXML/smile-format-specification[Smile]
679-
(binary JSON) data formats are currently supported.
676+
JSON and binary JSON (https://github.com/FasterXML/smile-format-specification[Smile]) data
677+
formats are both supported.
680678

681-
The encoder processes a `Publisher<?>`, as follows:
679+
The `Jackson2Decoder` uses Jackson's asynchronous, non-blocking parser to create a stream
680+
of ``TokenBuffer``'s and then each `TokenBuffer` is passed to Jackson's `ObjectMapper` to
681+
create a higher level object. When decoding to a multi-value publisher (e.g. `Flux`), the
682+
input stream can be a JSON array, or
683+
https://en.wikipedia.org/wiki/JSON_streaming[line-delimited JSON] if the content-type is
684+
"application/stream+json".
682685

683-
* If the `Publisher` is a `Mono` (that is, a single value), the value is encoded when available.
684-
* If media type is `application/stream+json` for JSON or `application/stream+x-jackson-smile`
685-
for Smile, each value produced by the `Publisher` is encoded individually (and followed
686-
by a new line in JSON).
687-
* Otherwise, all items from the `Publisher` are gathered in with `Flux#collectToList()`,
688-
and the resulting collection is encoded as an array.
686+
The `Jackson2Encoder` works as follows:
689687

690-
As a special case to the preceding rules, the `ServerSentEventHttpMessageWriter` feeds items
691-
emitted from its input `Publisher` individually into the `Jackson2JsonEncoder` as a
692-
`Mono<?>`.
688+
* For a single value publisher (e.g. `Mono`), simply serialize it.
689+
* For a multi-value publisher with "application/json", collect the values with
690+
`Flux#collectToList()` and then serialize the resulting collection.
691+
* For a multi-value publisher with a streaming media type such as
692+
`application/stream+json` or `application/stream+x-jackson-smile`, encode, write, and
693+
flush each value individually using a
694+
https://en.wikipedia.org/wiki/JSON_streaming[line-delimited JSON] format.
695+
* For Server Sent Events, the `Jackson2Encoder` is invoked individually for each event
696+
by the `ServerSentEventHttpMessageWriter` the resulting output flushed.
693697

694-
Note that both the Jackson JSON encoder and decoder explicitly back out of rendering
695-
elements of type `String`. Instead `String` instances are treated as low level content (that is,
696-
serialized JSON) and are rendered as-is by the `CharSequenceEncoder`. If you want a
697-
`Flux<String>` rendered as a JSON array, you have to use `Flux#collectToList()` and
698-
provide a `Mono<List<String>>` instead.
698+
By default `Jackson2Encoder` and `Jackson2Decoder` do not support serialization for
699+
elements of type `java.util.String`. Instead the default assumption is that a string
700+
or a sequence of strings represent serialized JSON content, to be rendered by the
701+
`CharSequenceEncoder`. If what you want is to render a JSON array from `Flux<String>`,
702+
use `Flux#collectToList()` and provide a `Mono<List<String>>` to be serialized.
699703

700704

701705

702706
[[webflux-codecs-streaming]]
703-
==== HTTP Streaming
707+
==== Streaming
704708
[.small]#<<web.adoc#mvc-ann-async-http-streaming,Same as in Spring MVC>>#
705709

706-
When a multi-value reactive type such as a `Flux` is used for response rendering, it may
707-
be collected to a `List` and rendered as a whole (for example, a JSON array), or it may be treated
708-
as an infinite stream with each item flushed immediately. The determination for which is
709-
which is made based on content negotiation and the selected media type, which may imply a
710-
streaming format (for example, `text/event-stream`, `application/stream+json`) or not
711-
(for example, `application/json`).
712-
713-
When streaming to the HTTP response, regardless of the media type (for example, `text/event-stream` and
714-
`application/stream+json`), it is important to send data periodically, since the write would
715-
fail if the client has disconnected. The send could take the form of an empty
716-
(comment-only) SSE event or any other data that the other side would have to interpret as
717-
a heartbeat and ignore.
710+
When streaming to the HTTP response (for example, `text/event-stream`,
711+
`application/stream+json`), it is important to send data periodically, in order to
712+
reliably detect a disconnected client sooner rather than later. Such a send could be an
713+
comment-only, empty SSE event or any other "no-op" data that would effectively serve as
714+
a heartbeat.
718715

719716

720717

0 commit comments

Comments
 (0)