With the project layout created by Maven, the Weather Microservice itself can be implemented. There are two tasks to accomplish:

• Implement a resource that provides temperature information to the outside world
• Configure the application's API context path

Each of these steps requires a single class, one for the temperature resource, named TemperatureResource, and one for the application's context path configuration, named WeatherApplication.

The temperature resource, which serves information about temperature, is represented by a Java class, named TemperatureResource, placed into the com.packtpub.microservices.weather.temperature package. In Maven's project structure, the package belongs to {project-root}/src/main/java folder. This is the folder where IDEs will create the package as well, as follows:

package com.packtpub.microservices.weather.temperature;

import javax.ws.rs.core.Response;

public class TemperatureResource {
   public Response getAverageTemperature() {
       //Not yet implemented in this step
   }
}

There is a zero-argument method, named getAverageTemperature(), defined. The return type of this method is javax.ws.rs.core.Response. The object comes from the Java API for RESTful Web Services, or JAX-RS for short. The Response object returned from the method contains mostly HTTP-protocol related information about response headers, body content, redirects, and much more.

Response is not instantiated explicitly. Instead, the process of Response creation follows a builder pattern, allowing the developer to obtain an instance from one of the static methods defined on the Response class. The static methods return a ResponseBuilder instance. Once the process of building the response with the ResponseBuilder instance is over and the response contains everything the programmer wants, the final Response object is constructed by calling the build() method on the ResponseBuilder chain. The process of building a simple Response is demonstrated in the following code sample:

package com.packtpub.microservices.weather.temperature;

import javax.ws.rs.core.Response;

public class TemperatureResource {
   public Response getAverageTemperature() {
       return Response.ok("35 Degrees")
               .build();
   }
}

The TemperatureResource of the Weather Microservice is implemented, but there are no instructions under which URI path the resource is available, or in simple words, it is not clear how to call this service. The resource's paths are declared as any additional metadata is, by means of a specialized annotation, @Path, from the javax.ws.rs package. This annotation accepts one string value, defining the path of the underlying resource. By applying the @Path("/temperature") annotation to the TemperatureResource class, JAX-RS is instructed to make the underlying set of endpoints available under the {http|https}://{host}:{port}/temperature URI.

The code with the resource path defined by means of a @Path annotation, is demonstrated as follows:

package com.packtpub.microservices.weather.temperature;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;

@Path("/temperature")
public class TemperatureResource {
   
   public Response getAverageTemperature() {
       return Response.ok("35 Degrees")
               .build();
   }
}

Defining the unique URI of the TemperatureResource class is not enough for the getAverageTemperature() method to be recognized by JAX-RS as a RESTful resource. First of all, the very existence of a Java method on a JAX-RS resource class does not automatically imply that JAX-RS considers such a method to be a specific resource. Java EE developers are free to create an arbitrary amount of methods inside a JAX-RS resource class without introducing any side effects. HTTP protocol declares several methods for client-server communication, as declared in RFC 2616. Each method has its own pre-defined purpose. For example, for retrieving information identified by the request URI, the GET method is intended to be used. Making getAverageTemperature() a JAX-RS resource available via an HTTP GET call means we put the @GET annotation from javax.ws.rs package on top of the method.

The final look of TemperatureResource is demonstrated in the following code block:

package com.packtpub.microservices.weather.temperature;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;

/**
* RESTful resource providing information about city's temperature
*/
@Path("/temperature")
public class TemperatureResource {

   /**
    * Provides average temperature from all the city's sensors. The temperature
    * is artificial.
    *
    * @return {@link Response} with constant temperature
    */
   @GET
   public Response getAverageTemperature() {
       return Response.ok("35 Degrees")
               .build();
   }
}

The combination of annotation metadata tells JAX-RS that the getAverageTemperature() method is available via an HTTP GET call under the path defined by the @Path("/temperature") annotation. Other HTTP methods are also available in the same package.

JAX-RS requires the developer to specify the URI path of resource classes exactly, as JAX-RS does not try to guess or derive the URI from the resource class name or from the name of any of its methods. Developers are free to name classes and methods deliberately. This results in zero interference between Java code and the RESTful interface of the Microservice.