Difference between revisions of "GxRest"
Manuele.simi (Talk | contribs) (→Correlation with the JAX-RS runtime) |
Manuele.simi (Talk | contribs) |
||
| Line 10: | Line 10: | ||
* to abstract over the HTTP-based details required by the gCube framework when invoking a remote service; | * to abstract over the HTTP-based details required by the gCube framework when invoking a remote service; | ||
* 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. | * 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. | ||
| − | |||
== Correlation with the JAX-RS runtime == | == Correlation with the JAX-RS runtime == | ||
| − | As mentioned, gxRest is generic but it relies on a [https://jcp.org/en/jsr/detail?id=311 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 [http://jersey.java.net/ Jersey], but it is not included in Java SE. | + | As mentioned, gxRest is generic but it relies on a [https://jcp.org/en/jsr/detail?id=311 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 [http://jersey.java.net/ 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 | + | At request side, a JAX-RS runtime is not strictly required as one of the requests implementation builds atop of plain HTTP protocol. |
== Distribution == | == Distribution == | ||
Revision as of 03:40, 26 April 2018
The gCube eXtensions to the Rest Protocol library (gxRest) provides a convenient round-trip interaction between a Restful web application and its client. The approach is completely independent from the JAX-RS implementation used to develop the web application, being entirely based on the javax.ws.rs package.
The library is consistently divided in:
- context-aware requests sent from a client to a web application
- outbound status-aware responses returned from a web application
- inbound responses received by a client.
Besides achieving independence over the web framework, the prominent features of the library are:
- 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 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.
Correlation with the JAX-RS runtime
As mentioned, gxRest is generic but it relies 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
gxRest is available as Maven artifact and can be added to a project with the following coordinates:
<dependency> <groupId>org.gcube.common</groupId> <artifactId>gxRest</artifactId> <version>0.0.2-SNAPSHOT</version> </dependency>
