Raw notes from Santiago Pericas-Geertsen's JAX-RS 2.1 Reloaded

Quick update on this latest "minor revision".

Reactive Extensions. Fits really well with JAX-RS API.

Server-Sent Events

Non-Blocking IO

Reactive Extensions

Asynchronous Processing in 2.0

Server Side @Suspended and AsyncResponse. Resume execution on a different thread.

Client side Future<T>. And InvocationCallback

Use of async in the midst of builders allows the delay of the invocation. Future doesn't allow you to know when it is safe to call get.

InvocationCallback allows you to pass in the thing to call when it effectively is safe to call get. But this doesn't easily allow composition: where the value for step 1 needs to be taken into account in step 2, for example. "pyramid of doom".

Some more use cases: composition, combining values, consume values of asyncronous tasks.

Now we can use CompletionStage<>. This fit really well bscause we didn't have to invent a new type, as we did with InvocationCallback.

Turns out that you might want to use RxJava, or some other Rx thing.

Two step process. 1. register a provider, 2. Override the default Invoker.

The ability to do this is an extension for JAX-RS. Impls are not required.

Server-Sent Events

Wanted to add in JAX-RS 2, now getting to it in 2.1.

Reviewed the basics of SSE. Now maintained by WHATWG.

Client API: get an SseEventSource target. Subscribe to it, passing in the handler. Open the event source. It is AutoClosable, so you can use try with resources.

Server API: SseEventSink and Sse. These can be passed to resource methods as @Context annotated arguments. SseBroadcaster and @Singleton annotation. The former is created by your application, not the runtime. You can use it to connect clients to the sse pipe, and also use it to broadcast events when you have them.

Non-Blocking IO

Motivation: enable higher throughput and more control over IO.

NIO Server

The existing StreamingOutput was still blocking.

Showed some iterations of NIO proposals. They suffered from operating at the level of byte streams, also it was hard to integrate with the JAX-RS pipeline.

Current proposal: Java 9 Flows. We want to use it. So we are creating copies of the required APIs. You don't have to use bytes. You can use objects. You can integrate with third party libraries.

Pattern: Publisher, Subscriber, Processor. How does this relate to JAX-RS?

Why and how to NIO? It's more complicated code. But it's useful for large payloads, which often involve collections. A collection of Pojos is a Publisher<Pojo>.

Added a new MessageBodyReader: NioBodyReader. Same for writer.

What about Filters and Interceptors? Still being discussed, but he did commit to having the feature in there.

NIO Clients

Need a new Invoker. Add nio() method you can throw in the builder chain, and then use the normal Flow API.


Publisher = Source, Subscriber = Sink. This lends itself to SSE. You can think of SSE as a special case of NIO. An SSE connection is just a Flow of SSE Events.