Thursday, July 9, 2009

RESTful Web Services for axis2


Introduction
WSDL 2.0 HTTP Binding defines a way to implement REST (Representational State Transfer) with Web services. Axis2 implements most defined in HTTP binding specification. REST Web services are a reduced subset of the usual Web service stack.
The Axis2 REST implementation assumes the following properties:
REST Web services are Synchronous and Request Response in nature.
When REST Web services are accessed via GET, the service and the operations are identified based on the URL. The parameters are assumed as parameters of the Web service. In this case the GET based REST Web services supports only simple types as arguments and it should adhere to IRI style.
POST based Web services do not need a SOAP Envelope or a SOAP Body. REST Web Services do not have Headers and the payload is sent directly.
_________________________
Axis2 can be configured as a REST Container and can be used to send and receive RESTful Web service requests and responses. REST Web services can be accessed using HTTP GET and POST.


Doing REST Web Services with HTTP POST
__________________________________________________________
Axis2 server, if REST is enabled, will act as both a REST endpoint and a SOAP endpoint. When a message is received, if the content type is text/xml and if the SOAPAction Header is missing, then the message is treated as a RESTful Message, if not it is treated as a usual SOAP Message.
On sending a message, the fact that the message is RESTful or not, can be decided from the client
__________________________________________________________
Sample REST - HTTP POST Client
_________________________________________________________
public class RESTClient {
private static String toEpr = "http://localhost:8080/axis2/services/MyService";

public static void main(String[] args) throws AxisFault {
Options options = new Options();
options.setTo(new EndpointReference(toEpr));

options.setProperty(Constants.Configuration.ENABLE_REST, Constants.VALUE_TRUE);
ServiceClient sender = new ServiceClient();
sender.engageModule(new QName(Constants.MODULE_ADDRESSING));
sender.setOptions(options);
OMElement result = sender.sendReceive(getPayload());
try {
XMLStreamWriter writer = XMLOutputFactory.newInstance()
.createXMLStreamWriter(System.out);
result.serialize(writer);
writer.flush();
} catch (XMLStreamException e) {
e.printStackTrace();
} catch (FactoryConfigurationError e) {
e.printStackTrace();
}
}
private static OMElement getPayload() {
OMFactory fac = OMAbstractFactory.getOMFactory();
OMNamespace omNs = fac.createOMNamespace(
"http://example1.org/example1", "example1");
OMElement method = fac.createOMElement("echo", omNs);
OMElement value = fac.createOMElement("Text", omNs);
value.addChild(fac.createOMText(value, "Axis2 Echo String "));
method.addChild(value);
return method;
}
}

--------------------------------------------------------------------------------------
Access a REST Web Service via HTTP GET
Axis2 allows users to access Web services that have simple type parameters via HTTP GET. For example, the following URL requests the Version Service via HTTP GET. But the Web service arriving via GET assumes REST. Other parameters are converted into XML and put into the SOAP Body.
http://127.0.0.1:8080/axis2/rest/version/getVersion

ENJOY

3 comments:

  1. Simple JAVA ResT webservice Client for flickr


    import java.net.HttpURLConnection;
    import java.net.InetSocketAddress;
    import java.net.Proxy;
    import java.net.SocketAddress;
    import java.net.URL;

    import javax.xml.parsers.DocumentBuilder;
    import javax.xml.parsers.DocumentBuilderFactory;

    import org.w3c.dom.Document;

    public class FlickrClient {
    public static void main(String[] args) {
    String flickrURL = "http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value&api_key=[yourflickrkey]";

    try {
    SocketAddress addr = new InetSocketAddress("[proxy]", 9090);
    Proxy proxy = new Proxy(Proxy.Type.HTTP, addr);
    URL u = new URL("http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value&api_key=[yourflickrkey]");
    HttpURLConnection uc = (HttpURLConnection) u.openConnection(proxy);
    uc.setRequestProperty("Accept", "*/*");
    uc.setRequestProperty("Accept-Charset", "ISO-8859-1,utf-8;q=0.7,*;q=0.7");
    uc.setRequestProperty("Accept-Language", "en-us,en;q=0.5");
    uc.setRequestProperty("Keep-Alive", "300");
    uc.setRequestProperty("ucection", "keep-alive");
    String proxyUser = "[netUserId]";
    String proxyPassword = "[netPassword]";
    uc.setRequestProperty("Proxy-Authorization", "NTLM " + new sun.misc.BASE64Encoder().encode((proxyUser + ":" + proxyPassword).getBytes()));

    DocumentBuilder docBuilder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
    Document doc = docBuilder.parse(uc.getInputStream());

    System.out.println(doc.getDocumentElement().getTagName());

    System.out.println();
    } catch (Exception e) {
    e.printStackTrace();
    }
    }
    }

    ReplyDelete
  2. Web Application Description Language (WADL)


    The style of documenting RESTful web services that this article has previously described is fine for use by developers, but it prevents tools from programmatically consuming such services and generating artifacts specific to programming languages. For example, a WSDL file can be consumed by various tools and proxies or by generated stubs that applications can use directly. A research effort from Sun Labs called Web Application Description Language (WADL) attempts to resolve some of these issues by providing a means to describe services in terms of schemas, HTTP methods, and the request or response structures exchanged.

    ReplyDelete
  3. Many of today's Web sites are opening up access to the information they provide and manage using APIs built on simple HTTP interactions. These APIs expand the potential use of such Web sites beyond browser-based interactions and support the creation of composite applications (or `mash-ups' in Web 2.0 parlance) that merge data from one or more sites in useful and interesting ways.

    Typically, these APIs are described using a combination of some sort of schema that defines the contents of the HTTP messages exchanged along with prose documentation that describes the Web endpoints available, the HTTP methods they support, and the message contents that should be included in requests and expected in responses. Often, site owners provide libraries for a variety of programming languages that can be used to interact with the site from an application. Whilst this style of documentation is fine for human consumption, it doesn't promote automatic tooling for working with such sites and it requires site owners to invest effort in developing and supporting APIs for their site in a variety of popular programming languages.

    This TR describes a new XML-based language that can be used to describe Web site APIs in a concise and machine process-able format. Use of this language promotes more precise description of Web site APIs and (with the availability of suitable tools) frees site owners from the effort of developing programming language APIs for their sites.

    ReplyDelete