Wednesday May 25, 2016

Putting Hypermedia Back in REST with JAX-RS

Implementing a fully-fledged hypermedia-driven REST API in your Java enterprise application enables more flexibility and resilience. Sebastian Daschner asserts in his new article that many developers claim they are using REST when, in fact, most web APIs are something between "RPC style" and "basic resources with HTTP semantics," except they are built without hypermedia.

Using real-world examples, he proves his point and shows how to accomplish a main goal of REST: having the server alone be in control of URLs and actively guide the client to the needed resources. Another REST benefit he discusses is having business logic reside only on the server to avoid duplicating the logic on the client. To accomplish that, he explores hypermedia-aware content types, such as Siren, that not only allow you to define links but also so-called actions--to describe how resources are accessed in ways other than by using simple GET calls.

Building on his examples, Daschner shows how to use the UriInfo component of JAX-RS to programmatically create URIs with information derived directly from JAX-RS classes and to construct the protocol, host, and ports depending on a given HTTP request. Finally, he shows how to use JSONP to programmatically create JSON structures, which enables you to be in full control of how a response can look and what content type is used.

To see these examples, learn about some important upfront choices, and access more examples he provides on GitHub, read the article.

Tuesday Sep 02, 2014

Greg Wilkins' Jetty/Servlet Sessions at JavaOne 2014

By Guest Blogger Reza Rahman

For the Java EE track at JavaOne 2014 we are highlighting some key sessions and speakers to better inform you of what you can expect, right up until the start of the conference.

To this end we recently interviewed Greg Wilkins. Greg is the mastermind behind Jetty and a long-time key contributor to the JCP, particularly for the foundational Servlet specification. In fact Greg is likely to be instrumental in the upcoming Servlet 4 specification slated to be included in Java EE 8. He will likely be the only person in the Servlet 4 expert group that is also part of the IETF HTTP 2 working group. We wanted to talk to Greg about his Jetty/Servlet sessions at JavaOne 2014 and HTTP 2 generally:

font-family: Arial, Verdana, sans-serif; font-size: 12px; line-height: 18px;">Greg has several sessions on the track that he talked about:

  • Jetty Features: In his open-ended Birds-of-a-Feather session, Greg will share the latest features added and to be considered in Jetty.
  • Into the Wild with Servlet Async IO: In this deeply technical session, Greg will be exploring the ins-and-outs of the Servlet 3.1 asynchronous I/O feature. If this is a topic that interests you, the session is probably your best opportunity to gain knowledge from a true subject matter expert.

Bear in mind, Oracle's own Ed Burns will have a detailed session on Servlet 4/HTTP 2. Besides Greg's sessions, we have a very strong program for the Java EE track and JavaOne overall - just explore the content catalog. If you can't make it, you can be assured that we will make key content available after the conference just as we have always done.

Tuesday Aug 14, 2012

Enterprise JavaFX Deployment with LightView: Part 3 now on otn/java

A new article by Java Champion Adam Bien, now up on otn/java, titled “Enterprise JavaFX Deployment with LightView: Part 3,” explores ways to use Maven 3 to build and deploy the LightView application in all available deployment modes. In addition, Bien shows how to sign and deploy LightView with a Java EE 6 application.

Bien explains the basics:

“LightView uses the HTTP (REST) protocol to communicate with the back-end server. For the realization of back-end communication, an external library—the Jersey client—is used. LightView connects with the back end (LightFish) at startup time, so it is not suitable to lazy-load the Jersey dependencies for optimization purposes. Furthermore, multiple JAR files are hard to handle for standalone applications; you have to set up the class path correctly and keep all the moving parts consistent. The most convenient way to deploy Java (and JavaFX) applications is simply by starting them with java -jar my-killer-app.jar and deploying a single file that contains all the dependencies.”

He shows how the class files are packaged with the javafxpackager, which is shipped with the JavaFX 2 SDK, using the exec-maven-plugin and explains the core tasks achieved by Maven and describes the what javafxpackager does behind the scenes. He then shows how the LightView application operates and interacts with LightFish.

Bien concludes by emphasizing that the richness of JavaFX lies in the fact that it is another Java library. “Because JavaFX is ‘just’ an additional Java library, all of the established build, test, and deployment infrastructure can be reused. You can develop JavaFX applications using any integrated development environment (IDE) you like. And best of all, you can use a single language in a project, from the Java EE back end to the JavaFX front end.”

Check out the article here.


Insider News from the Java Team at Oracle!



« May 2016