|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 5 of 7
The suggestive responses are simple and easy to parse when they are one per line as they are in Listing 5. It seems unnecessary to involve angle brackets although you certainly can wrap the responses in XML if you choose. The goal here is to make a simple, lightweight request that can be used from a variety of applications (thick clients, Ajax applications, command-line tools, and so on) to do spell checking. Focusing on logical names for information resources (correctly spelled words or lists of suggestions) makes substantive language bindings or contracts unnecessary. And it is easy to get both reuse and the freedom to change implementations without breaking the clients.
Sun is adding support for REST to the JEE stack. REST support in JEE hasn't been completely lacking -- servlets can respond to HTTP requests, after all -- but now a legitimate set of guidelines for building enterprise RESTful APIs with the Java technology stack is available.
JSR 311 (JAX-RS) tries to limit the degrees of freedom in REST and focuses on using annotations to make plain old Java objects (POJOs) and resources available through HTTP. (A reference implementation called Jersey is available from the GlassFish project.) Jérome Louvel has made a nice extension to Restlet to support the JAX-RS effort. This article is not intended to be a comprehensive introduction to this specification, but it should be enough to get you going quickly.
The JAX-RS API lets you annotate a class to indicate which HTTP contexts should trigger method invocations, as illustrated
by the @Path annotation in Listing 6.
Restletpackage net.bosatsu.restlet.jaxrs;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.GET;
@Path("sample")
public class SampleResource {
private String message;
public SampleResource() {
this("Hello");
}
public SampleResource(String message) {
this.message = message;
}
@GET
@Produces("text/html")
public String getHTML() {
StringBuffer sb = new StringBuffer("<html><body>");
sb.append(message);
sb.append("</body></html>");
return sb.toString();
}
@GET
@Produces("text/xml")
public String getXML() {
StringBuffer sb = new StringBuffer("<message>");
sb.append(message);
sb.append("</message>");
return sb.toString();
}
@GET
@Produces("text/plain")
public String getPlain() {
return message;
}
}
Whichever JSR 311 container is told about this resource will set up the necessary infrastructure to route requests to /sample to instances of the SampleResource class. Specific methods to call are matched by the JSR 311 engine in order based upon the context of the request. This matching
process potentially includes subpath information, HTTP method, requested MIME type, and so on. The first match that it finds
will be used. An otherwise unconstrained GET request to /sample will result in the getHTML() method being invoked, as you can see in Listing 6. Should the client indicate a preference for a MIME type other than HTML,
however, this method will no longer match, and some other method will be invoked.