WAS v8.5 > End-to-end paths > Web services - RESTful services

Use WADL to generate service documentation

Web Application Description Language (WADL) is a description language for HTTP-based applications. It is currently a World Wide Web Consortium (W3C) Member Submission. WADL can be used by programs to give information about the service in a machine-processable method. For instance, we can use an Extensible Stylesheet Transformation (XSLT) document to transform the WADL documentation using a custom XSLT and a XSLT processor.

By default, a WADL document can be requested for a particular resource by invoking an HTTP OPTIONS request for any Java API for RESTful Web Services (JAX-RS) URL. We can issue an OPTIONS request with most HTTP clients. The WADL document returned from the request describes the resource using information from the JAX-RS annotations.

WADL is a developing standard which helps describe the services available to users. WADL documents are written in XML. Using XSTL or XML parsers, developers can generate documentation for the service. In some cases, users may develop clients to dynamically understand the RESTful service by inspecting the WADL document.

Using IBM JAX-RS, developers can generate a JAXB XML representation of a WADL document describing all of the resources available in the application. The JAXB representation can be returned from a JAX-RS resource method. Then, the WADL document resource is treated like any other JAX-RS resource and can be used by clients.

  1. Configure the development environment

  2. Define the resources in JAX-RS web applications.

    Resources are the basic building block of a RESTful service. Resources can contain static or dynamically updated data. Examples of resources from an online book store application include a book, an order from a store, and a collection of users. By identifying the resources in the application, we can make the service more useful and easier to develop.

  3. Configure the JAX-RS application

    We can configure JAX-RS applications in multiple ways depending on your needs. To take advantage of the Java EE 6 functionality, we can use the annotation scanning capabilities. By using annotation scanning, we can omit a JAX-RS javax.ws.rs.core.Application subclass or have a minimally defined javax.ws.rs.core.Application subclass. Alternatively, we can specify the IBM JAX-RS servlet or filter to use the functionality available in the IBM JAX-RS servlet and filter.

    Using one of the JAX-RS v1.1 configuration methods, we can omit a javax.ws.rs.core.Application subclass in the application or have a javax.ws.rs.core.Application subclass that returns an empty set of classes to inform the JAX-RS runtime environment to find and use all the JAX-RS classes in the application. You might want to use this method when we do not want to manually add every relevant JAX-RS class to a javax.ws.rs.core.Application subclass as you develop the application.

    By specifying the specific IBM JAX-RS servlet and filter, we can take advantage of and ensure specific IBM JAX-RS behavior. For example, using the IBM JAX-RS filter can be helpful in developing a web application with a mix of JAX-RS resources and JSP files with the same URL patterns.

    Even though there is a JAX-RS V1.1 configuration method that supports the use of an optional web.xml file, to specify security constraints or roles, or to take advantage of other features enabled using a web.xml file, specify the information in a web.xml file.

    Choose one of the following three methods to configure your JAX-RS application:

  4. Use WADL to generate service documentation.

    We can also build our own WADL document using the org.apache.wink.common.model.wadl.WADLGenerator. WADLGenerator builds a JAXB annotated object model so we can return it as an entity response in an @OPTIONS resource method as the response entity.

  5. Assemble JAX-RS web applications.

    After you develop the Java class files for the JAX-RS web application and edit web.xml to enable the JAX-RS servlet, you are ready to assemble the application. Assemble the web application into a web archive (WAR) package. We can assemble the WAR package into an EAR package if required.

  6. Deploy JAX-RS web applications

    After we have assembled your JAX-RS web application, you need to deploy the web archive (WAR) package or the EAR package onto the application server.


Reference:
Web services specifications and APIs


+

Search Tips   |   Advanced Search