Santiago,
no I have not spent any particular time into the effect, as I think it is irrelevant for JAX-RS as an international standard (in comparison to the implications for products implementing that standard): First, as soon as Servlet will support it, and as soon as HTTP/2 gains broad popularity, people will ask for it, and we have to have a prepared answer in out pockets then -- independent of whether this implies complexity or not. Second, I do not propose to finally _expose_ it in the API, I solely kicked-off discussion what the implications on JAX-RS _might_be_ and how JAX-RS should and / or could react upon this demand. For example, it possibly might be enough if JAX-RS SPI translates http/2 into http/1 "under the hood" and keept the API as it is, i. e. transform binary-textual representation, or split up multiple intra-request-streams into separate, independent requests, then there might be no implication on the API. What I intend is getting the discussion started; I do not have any particular solution in mind. Neither do I say that HTTP/2 is particularly well-done. But all this is irrelevant once that standard is used in-field.
If you ask me for the use case, there is one actually I have already (real world example adapted from what our software product actually does already):
Our product offers complex XML representations, like say a project plan. Such a project plan XML references lots of related items, like say the vCards of task leads, where each vCard contains the person's photograph. If someone opens the project plan, normally only the top information is shown, then clicking down the timeline more and more details are shown, until the client shows all the vCards of all the project leads. What our software did in the first release was iterating all the references, hence loading all the vCards' photos sequentially. This is really painfully slow. The second release loaded vCards only when shown, but then still loads the photo as a secondary request. This is faster, but still seqentially.
An optimization would be to tell the JAX-RS client to loads the project, but to include the requests for the references as http/2 low-priority background streams (this is what it was made for when loading complex HTML pages containg lots of photos). What I would expect then would be that the high-priority "main" request (the project plan XML) is loaded first, while all the referenced low-priority photos are returned asynchronously in an unspecified order. Hence, our application would show up the project plan rather immediately to the user, but the vCards and photos would pop up shortly after. Reactive GUIs (like JavaFX) are already prepared for this style of progressing result presentation), and http/2 perfectly fits in this style of "parallel REST".
Regards
-Markus
From: Santiago Pericas-Geertsen [mailto:Santiago.PericasGeertsen_at_oracle.com]
Sent: Freitag, 27. März 2015 14:25
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: Support for HTTP/2 and HPACK
Hi Markus,
Have you given any thought to the implications of these new technologies on JAX-RS? Is there really a need to “expose" HTTP/2 concepts in the JAX-RS API? If so, what is the use case?
— Santiago
On Mar 26, 2015, at 5:51 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
Experts,
in reaction to Ed Burns interesting talk about the status of HTTP/2 and HPACK support in Servlet 4 yesterday at JavaLand conference I just filed a marker in the spec JIRA tracker as an umbrella for any resulting issues.
Once HTTP/2 and HPACK gain attention, we have to expect increasing requests for support in JAX-RS. As Servlet 4 supports it, I think it would be a good idea to discuss how the JAX-RS specification should deal with HTTP/2 and HPACK.
You can find the JIRA entry here: <
https://java.net/jira/browse/JAX_RS_SPEC-512>
https://java.net/jira/browse/JAX_RS_SPEC-512
Regards
-Markus