Packages

abstract class EntityStreamingSupport extends AnyRef

Entity streaming support trait allowing rendering and receiving incoming Source[T, _] from HTTP entities.

See JsonEntityStreamingSupport or CsvEntityStreamingSupport for default implementations.

Source
EntityStreamingSupport.scala
Linear Supertypes
Type Hierarchy
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. EntityStreamingSupport
  2. AnyRef
  3. Any
Implicitly
  1. by any2stringadd
  2. by StringFormat
  3. by Ensuring
  4. by ArrowAssoc
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. Protected

Instance Constructors

  1. new EntityStreamingSupport()

Abstract Value Members

  1. abstract def contentType: ContentType

    Write-side, defines what Content-Type the Marshaller should offer and the final Content-Type of the response.

  2. abstract def getFramingDecoder: Flow[ByteString, ByteString, NotUsed]

    Read-side, decode incoming framed entity.

    Read-side, decode incoming framed entity. For example with an incoming JSON array, chunk it up into JSON objects contained within that array.

  3. abstract def getFramingRenderer: Flow[ByteString, ByteString, NotUsed]

    Write-side, apply framing to outgoing entity stream.

    Write-side, apply framing to outgoing entity stream.

    Most typical usage will be a variant of Flow[ByteString].intersperse.

    For example for rendering a JSON array one would return Flow[ByteString].intersperse(ByteString("["), ByteString(","), ByteString("]")) and for rendering a new-line separated CSV simply Flow[ByteString].intersperse(ByteString("\n")).

  4. abstract def parallelism: Int

    Write-side / read-side, defines if (un)marshalling should be done in parallel.

    Write-side / read-side, defines if (un)marshalling should be done in parallel.

    This may be beneficial marshalling the bottleneck in the pipeline.

    See also parallelism and withParallelMarshalling.

  5. abstract def supported: ContentTypeRange

    Read-side, what content types it is able to frame and unmarshall.

  6. abstract def unordered: Boolean

    Write-side / read-side, defines if (un)marshalling of incoming stream elements should be preserved or not.

    Write-side / read-side, defines if (un)marshalling of incoming stream elements should be preserved or not.

    Allowing for parallel and unordered (un)marshalling often yields higher throughput and also allows avoiding head-of-line blocking if some elements are much larger than others.

    See also parallelism and withParallelMarshalling.

  7. abstract def withContentType(range: ContentType): EntityStreamingSupport

    Write-side, defines what Content-Type the Marshaller should offer and the final Content-Type of the response.

    Write-side, defines what Content-Type the Marshaller should offer and the final Content-Type of the response.

    EntityStreamingSupport traits MUST support re-configuring the offered ContentType. This is due to the need integrating with existing systems which sometimes excpect custom Content-Types, however really are just plain JSON or something else internally (perhaps with slight extensions).

    NOTE: Implementations should specialize the return type to their own Type!

  8. abstract def withParallelMarshalling(parallelism: Int, unordered: Boolean): EntityStreamingSupport

    Write-side / read-side, defines parallelism and if ordering should be preserved or not of Source element marshalling.

    Write-side / read-side, defines parallelism and if ordering should be preserved or not of Source element marshalling.

    Sometimes marshalling multiple elements at once (esp. when elements are not evenly sized, and ordering is not enforced) may yield in higher throughput.

    NOTE: Implementations should specialize the return type to their own Type!

  9. abstract def withSupported(range: ContentTypeRange): EntityStreamingSupport

    Read-side, allows changing what content types are accepted by this framing.

    Read-side, allows changing what content types are accepted by this framing.

    EntityStreamingSupport traits MUST support re-configuring the accepted ContentTypeRange.

    This is in order to support a-typical APIs which users still want to communicate with using the provided support trait. Typical examples include APIs which return valid application/json however advertise the content type as being application/javascript or vendor specific content types, which still parse correctly as JSON, CSV or something else that a provided support trait is built for.

    NOTE: Implementations should specialize the return type to their own Type!