GxRest/GxJRS

Scope and Features

gxJRS is much more advanced than gxHTTP and offers fully-fledged extensions built on top of JAX-RS and gxHTTP.

Prominent features of gxJRS are:

• to achieve independence from the web framework used to develop the web application;
• to guarantee the correctness of requests/responses across the D4Science infrastructure;
• to abstract over the HTTP-based details required by the gCube framework when invoking a remote service;
• to avoid that each service implements its own conventions over the returned responses;
• to return error responses at the familiar (for any Java programmer) level of exceptions and error codes, while web frameworks usually just let return an HTTP status, headers and streams.

Requests

• • context-aware requests sent from a client to a web application

Requests

• • outbound status-aware responses returned from a web application
  • inbound responses received by a client.

Correlation with the JAX-RS runtime

The gxJRS approach is independent from the JAX-RS implementation used to develop the web application, being entirely based on the javax.ws.rs package. However, some features rely on a JAX-RS runtime implementation. It dynamically loads the implementation available on the classpath and uses it for modeling and sending the responses and requests. The reference implementation for JAX-RS is named Jersey, but it is not included in Java SE. You must explicitly add Jersey or another JAR-RS implementation to your classpath.

At request side, a JAX-RS runtime is not strictly required as one of the requests implementation builds atop of plain HTTP protocol.

Distribution

gxJRS is available as Maven artifact and can be added to a maven-based project with the following dependency:

<dependency>
	<groupId>org.gcube.common</groupId>
	<artifactId>gxJRS</artifactId>
	<version>LATEST</version>
</dependency>