The expert group’s work on JAX-RS 2.1 started this week with a call for statements on Hypermedia and reactive programming by spec lead Santiago Pericas-Geertsen. I chimed in and started both threads with elaborate introductions on both topics, soon picked up by Case Ley, Red Hat’s Bill Burke and more experts, providing valuable input from different angles. Later the topic of security was strived, too. The discussions started very lively, while Oracle was rather reluctant with judgements, which is very appreciated by the experts, as it shows that Oracle actually is interested in third party opinions. It is not foreseeable in which direction the discussions will actually lead us, so it is thrilling to watch the threads and get a feeling how an international standard evolves. I want to invite you to read along and participate with your comment on the open community forum for JSR 370: users@jax-rs-spec.java.net (https://java.net/projects/jax-rs-spec/lists/users/archive). The input is valuable for us, as we get a better understanding of the what you, the actual users, are doing with and demanding of JAX-RS.
If you’re not familiar with the discussed topics, let me give you a very short introduction. Longer statements can be found on the mailing list for reactive API and hypermedia API.
Hypermedia API
According to Richardson’s REST Maturity Model (see this great introduction by Martin Fowler), “real” RESTfulness is gained by using hyperlinks to change the application’s process state. Least applications do that currently, as most programmer’s are not familiar with the idea behind this principle, typically called “HATEOAS” (hypermedia as the engine of application state). As a result, JAX-RS 2.0 provided only core and algorithmic support. The idea for JAX-RS 2.1 is to provide a more sophisticated and declarative kind of API. Besides that, we’re dicussing the idea using hyperlinks to dissemble object trees at rendering, which allows to reduce the size of transmitted representations by sending links instead of compound documents and other smart things. Interestingly it is the latter which drives the discussion currently, while that kind of links (structural links) are actually not what HATEOS is talking about (that would be transitional links), but it seems there is more interest in structural links than in transitional links. This doesn’t surprise, as splitting structures is a common topic for programmers, while HATEOS is not — at least, not yet. Maybe it will change when JAX-RS supports it…?
Reactive API
In the last years more and more push technologies conquered the web area, like SSE and WebSockets. These allow a server to send information to the client at arbitrary time. Hence, a client is not bound to polling anymore, but simply can once register its interest in particular types of events, and when such events occur, the server will inform the client. Not only this reduces the workload for all parties (client, server, network) and provides reduced delay, it also opens up the way for a simpler way to write software. Typically, software dealing with events, is reacting in some way when that event occurs. A common way are event handlers in GUIs. When a button is clicked, some procedure is executed. Often the reaction is to fire events in turn. In GUIs is is often simple, while in client-server scenarios often rather huge chains exists. The paradigm built upon these chains is called “Complex Event Processing” and defines event-process-chains, where sequences of events and processes are defined as an application intention (compared to uncoupled sequences of events as known from GUIs). Reactive programming picks up this idea and provides a paradigm that in core says that these chains are programming objects. Existing frameworks for reactive programming, like the Beans Binding Package of JavaFX, already provide a (very) good (fluent) help to program in a reactive way. Particularly JavaFX’s incarnation of this paradigm is already installed on rather any PC, rather comprehensive, and well understood by the Java community. Hence, it would make sense to support reactive programming using exactly that package in JAX-RS, as it would simplify programming things like “When stock ticker update received or order limit was changed then update order book”.
Security API
Authentication and authorization are core demands in rather any business application. There are many APIs and SPIs around these topics, jointly names “security”, but there is no single way for an JAX-RS application vendor to declare “this method must only be invoked by administrators, that method is publicly available, while all other methods demand at least a valid login-in by a known user account”. As JAX-RS often is used in Java EE applications, often Java EE’s security is used in JAX-RS 2.0. But JAX-RS does not demand Java EE, but explicitly allows running in pure Servlet environmoments, or even “worse” in pure Java SE environments. Both do not mandate any particular declarative security APIs. As a result, the WORA principle is void, as your now need to write three different JAX-RS applications for the same purpose: One for Java SE using possibly home-brewn security, one for Servlet API (possibly using a programmatic API), and one for Java EE, using that one’s annotations. The vision now is to have one single API on a high level, which JAX-RS will use to analyze the needs of the application, and that will make use of the best SPI under the hood, for example, use JASPIC on Java EE or JAAS on Java SE.
I’m curious how things will evolve and will be glad to read your comments! If we do things right now, finally JAX-RS 2.1 (or “JAX-RS.next” as RI project lead Marek Potociar names it) cold become the next common-purpose programming frameworks standard, just as Roy Thomas Fielding’s dissertation depicts JAX-RS’s underlying REST paradigm as the ultimate distributed application architecture.
Regards
-Markus
(JSR 370 Expert Group)
Head Crashing Informatics 