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

Use custom entity formats

Even though the Java API for RESTful Web Services (JAX-RS) runtime environment includes several entity providers for handling serialization from and deserialization to Java types, it does not support all possible media types. We can develop a custom entity provider to handle binding Java types to message bodies.

If your JAX-RS web application requires that additional Java types or media types are supported beyond what the JAX-RS APIs support, we can add a custom entity provider to the application. Any custom-defined entity provider takes precedence over the entity providers that are included in the JAX-RS runtime environment. Unlike resources, providers are always singleton beans.

  1. Configure the development environment.

    Before you start developing JAX-RS applications, set up your development environment by adding the JAX-RS libraries on the classpath.

  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 have 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. Implement custom entity formats

    If your JAX-RS web application requires support for additional Java types or media types that are not supported by the JAX-RS APIs, we can add a custom entity provider to the application.

  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 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 your Web archive (WAR) package or the EAR package onto the application server.


Related

Deploy JAX-RS web applications


+

Search Tips   |   Advanced Search