Space: Apache Tuscany Docs 2.x
(http://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x)
Page: SCA Java binding.rest
(http://cwiki.apache.org/confluence/display/TUSCANYxDOCx2x/SCA+Java+binding.rest)
Edited by Luciano Resende:
---------------------------------------------------------------------
h3. <binding.rest> Introduction
The Tuscany Java SCA runtime supports Representational State Transfer (REST)
services invocations via the <binding.rest> extension. Tuscany REST binding
leverage JAX-RS Standards based annotations to map business operations to HTTP
operations such as POST, GET, PUT and DELETE and utilizes Tuscany Databindings
to provide support for different wire formats such as JSON, XML, Binary, etc
shielding the application developer from contaminating his business logic with
code to handle payload production/transformation details.
h3. Using the Tuscany REST binding
The primary use of the REST binding is to provide business services over HTTP
in a distributed fashion. The simplest way to use the REST binding is to
declare a business service that can be shared over the web and provide an HTTP
address where one can access the service. This service is declared in an SCA
composite file.
{code}
<component name="Catalog">
<implementation.java class="services.store.FruitsCatalogImpl"/>
<service name="Catalog">
<tuscany:binding.rest uri="http://localhost:8085/Catalog";>
<tuscany:wireFormat.json />
<tuscany:operationSelector.jaxrs />
</tuscany:binding.rest>
</service>
</component>
{code}
Another way of implementing a REST service is to use a collection interface
that matches the actions of the HTTP protocol. In this case, the methods must
be named post, get, put, and delete. Tuscany ensures that the proper method is
invoked via the request and response protocol of HTTP:
{code}
public class TestGetImpl {
public InputStream get(String id) {
return new ByteArrayInputStream(("<html><body><p>This is the service
GET method, item=" + id + "</body></html>").getBytes());
}
}
{code}
So using the common verbs of HTTP and Java object serialization, one can
implement services and run them anywhere the HTTP protocol is implemented. The
service developer or implementer simply creates methods for post, get, put, and
delete, and a business collection such as a shopping cart, telephone directory,
insurance form, or blog sites can be created. See the Tuscany module
binding-rest-runtime for complete examples.
h3. Mapping business interfaces to HTTP Operations using JAX-RS Standard
Annotations
JAX-RS offers standards based annotations that allow properly configuration of
the REST service endpoint and mappings of specific HTTP operations (e.g. get,
put, post, delete) to java operations. The following subset of JAX-RS
annotations are currently supported :
h4. URI Mappings
{code}
@Path
@Path("{id}")
@PathParam("id")
{code}
h4. Operation Mappings
{code}
@GET
@PUT
@POST
@DELETE
{code}
h4. Enabling JAX-RS annotation processing
In order to enable JAX-RS annotation processing, a component need to be
configured to use JAX-RS Operation Selector.
{code}
<component name="Catalog">
<implementation.java class="services.store.FruitsCatalogImpl"/>
<property name="currencyCode">USD</property>
<service name="Catalog">
<tuscany:binding.rest
uri="http://localhost:8085/Catalog";>
<tuscany:wireFormat.json />
<tuscany:operationSelector.jaxrs />
</tuscany:binding.rest>
</service>
<reference name="currencyConverter"
target="CurrencyConverter"/>
</component>
{code}
{info}
Integration with a existent JAX-RS engine might help on processing the full set
of JAX-RS annotations. I have started looking into leveraging Wink
resourceProcessor or related code to help on this layer.
{info}
h3. Mapping RPC style calls over HTTP GET
In some cases, there isn't a simple mapping of a business operation as
resources, but there is still a desire to take advantage of HTTP caching and
other benefits that HTTP GET type of operations provide. In order to accomplish
this, binding.rest has built in functionality that allows you to map RPC style
calls to HTTP GET operations.
h4. Client Invocation
The URL schema follows a simple pattern :
- <base service URI> ?*method=*<operation name>&*parm1=*<value>&*parm2=*<value>
{code}
http://localhost:8085/EchoService?method=echo&msg=Hello RPC
{code}
{code}
http://localhost:8085/EchoService?method=echoArrayString&msgArray=Hello
RPC1&msgArray=Hello RPC2"
{code}
h4. Mapping QueryStrings to Business Operation parameters
Standard JAX-RS annotation @QueryParam is used to map parameters sent over HTTP
GET invocations using query string to business operation parameter
{code}
@Remotable
public interface Echo {
String echo(@QueryParam("msg") String msg);
int echoInt(int param);
boolean echoBoolean(boolean param);
String [] echoArrayString(@QueryParam("msgArray") String[] stringArray);
int [] echoArrayInt(int[] intArray);
}
{code}
h4. Enabling RPC to HTTP GET mapping
In order to enable automatically mapping, a component need to be configured to
use RPC Operation Selector.
{code}
<component name="Catalog">
<implementation.java class="services.store.FruitsCatalogImpl"/>
<property name="currencyCode">USD</property>
<service name="Catalog">
<tuscany:binding.rest
uri="http://localhost:8085/Catalog";>
<tuscany:wireFormat.json />
<tuscany:operationSelector.rpc />
</tuscany:binding.rest>
</service>
<reference name="currencyConverter"
target="CurrencyConverter"/>
</component>
{code}
h3. Wire Formats
This binding will support two styles of wire formats and will be used to
control what type of payload will be generated by the service:
- hardWired : where you hard code the wire format expectations in the composite
when configuring the binding. In the example below, service will be using JSON
payload.
{code}
<binding...>
<wireFormat.json>
</binding...>
{code}
- dynamic : based on Content-Type header for request and Accept header for
response. In the case below, the request content will be parsed based on the
Content-Type request header and the response payload will be based on the
request Accept header.
{code}
<binding...>
<wireFormat.dynamic>
</binding...>
{code}
{info} In progress {info}
h3. Cache control using ETags, Last-Modified and other HTTP Headers
The HTTP specification provides a set of methods for HTTP clients and servers
to interact. These methods form the foundation of the World Wide Web. Tuscany
implements many of these methods a binding interface to a collection. The main
methods are:
* GET - retrieves an item from a collection
* POST - creates or adds an item to a collection
* PUT - updates or replaces an item in a collection
* DELETE - removes an item in a a collection
The HTTP specification (HTTP 1.1 Chapter 13 - Caching) also provides a
mechanism by which these methods may be executed conditionally. To perform
conditional methods, an HTTP client puts 3 items in the HTTP request header:
* ETag - entity tag, a unique identifier to an item in a collection. Normally
created and returned by the server when creating (POST) a new item.
* LastModified - an updated field. Normally a string containing a date and time
of the last modification of the item.
* Predicate - a logical test (e.g. IfModified, IfUnmodified) to use with the
ETag and LastModified to determine whether to act.
The complete list of predicates is given in the HTTP specification.
The most common use of conditional methods is to prevent two requests to the
server instead of one conditional request. For example, a common scenario is to
check if an item has been modified, if not changed update it with a new
version, if changed do not update it. With a conditional PUT method (using the
IfUnmodifed predicate and a LastModified date), this can be done in one action.
Another common use is to prevent multiple GETs of an item to ensure we have a
valid copy. Rather than doing a second request of a large item, one can do a
conditional GET request (using an IfModified predicate and a LastModified
date), and avoid the second request if our object is still valid. The server
responds with either a normal response body, or status code 304 (Not Modified),
or status code 412 (precondition failed).
Default cache control is done by using generated ETags based on response
content checksum. To avoid data to be overwriten during concurrent updates,
include an HTTP If-Match header that contains the original content ETag value.
If you want to force an update regardless of whether someone else has updated
it since you retrieved it, then use If-Match: * and don't include the ETag.
h4. Declarative cache control
In order to allow for better flexibility, and re-usability of the components
exposed as REST services, there is an option to declare cache controls when
configuring the REST Binding as show the example below :
{code}
<component name="CustomerService">
<implementation.java
class="services.customer.CustomerServiceImpl"/>
<service name="CustomerService">
<tuscany:binding.rest
uri="http://localhost:8085/Customer";>
<tuscany:wireFormat.xml />
<tuscany:operationSelector.jaxrs />
<tuscany:http-headers>
<tuscany:header name="Cache-Control"
value="no-cache"/>
<tuscany:header name="Expires" value="-1"/>
<tuscany:header name="X-Tuscany"
value="tuscany"/>
</tuscany:http-headers>
</tuscany:binding.rest>
</service>
</component>
{code}
{info}
This could be enhanced to enable more complex injection of fields to cache
control headers.
{info}
h3. Store scenarios goes REST - Catalog Services using binding.rest
Below is our Store Catalog exposed as REST services utilizing the new
binding.rest.
Let's start by looking on how the component gets defined and configured in the
composite file, particularly the following details :
- binding.rest uri defines the Catalog service endpoint
- wireFormat.json configure the service to use JSON as the payload
- operationSelector.jaxrs configure the binding to use JAX-RS annotations to
map the HTTP operations to business operations
{code}
<composite xmlns="http://docs.oasis-open.org/ns/opencsa/sca/200912";
xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.1";
targetNamespace="http://store";
name="store">
<component name="Catalog">
<implementation.java class="services.store.FruitsCatalogImpl"/>
<property name="currencyCode">USD</property>
<service name="Catalog">
<tuscany:binding.rest
uri="http://localhost:8085/Catalog";>
<tuscany:wireFormat.json />
<tuscany:operationSelector.jaxrs />
</tuscany:binding.rest>
</service>
<reference name="currencyConverter"
target="CurrencyConverter"/>
</component>
<component name="CurrencyConverter">
<implementation.java
class="services.store.CurrencyConverterImpl"/>
</component>
</composite>
{code}
Below is the Catalog Interface utilizing JAX-RS standard annotations to map
HTTP operations to business operations.
{code}
package services.store;
import javax.ws.rs.DELETE;
import javax.ws.rs.GET;
import javax.ws.rs.POST;
import javax.ws.rs.PUT;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import org.oasisopen.sca.annotation.Remotable;
@Remotable
public interface Catalog {
@GET
Item[] getAll();
@GET
@Path("{id}")
Item getItemById(@PathParam("id") String itemId);
@POST
void addItem(Item item);
@PUT
void updateItem(Item item);
@DELETE
@Path("{id}")
void deleteItem(@PathParam("id") String itemId);
}
{code}
Below is the Fuit catalog implementation
{code}
@Scope("COMPOSITE")
public class FruitsCatalogImpl implements Catalog {
@Property
public String currencyCode = "USD";
@Reference
public CurrencyConverter currencyConverter;
private Map<String, Item> catalog = new HashMap<String, Item>();
@Init
public void init() {
String currencySymbol =
currencyConverter.getCurrencySymbol(currencyCode);
catalog.put("Apple", new Item("Apple", currencySymbol +
currencyConverter.getConversion("USD", currencyCode, 2.99)));
catalog.put("Orange", new Item("Orange", currencySymbol +
currencyConverter.getConversion("USD", currencyCode, 3.55)));
catalog.put("Pear", new Item("Pear", currencySymbol +
currencyConverter.getConversion("USD", currencyCode, 1.55)));
}
public Item[] getAll() {
Item[] catalogArray = new Item[catalog.size()];
catalog.values().toArray(catalogArray);
return catalogArray;
}
public Item getItemById(String itemId) {
return catalog.get(itemId);
}
public void addItem(Item item) {
catalog.put(item.getName(),item);
}
public void updateItem(Item item) {
if(catalog.get(item.getName()) != null) {
catalog.put(item.getName(), item);
}
}
public void deleteItem(String itemId) {
if(catalog.get(itemId) != null) {
catalog.remove(itemId);
}
}
}
{code}
Change your notification preferences:
http://cwiki.apache.org/confluence/users/viewnotifications.action
