How to implement a Restlet JAX-RS handler which is a thin proxy to a RESTful API, possibly implemented in the same java process?

Question

We have two RESTful APIs - one is internal and another one is public, the two being implemented by different jars. The public API sort of wraps the internal one, performing the following steps:

1. Do some work
2. Call internal API
3. Do some work
4. Return the response to the user

It may happen (though not necessarily) that the two jars run in the same Java process.

We are using Restlet with the JAX-RS extension.

Here is an example of a simple public API implementation, which just forwards to the internal API:

@PUT
@Path("abc")
public MyResult method1(@Context UriInfo uriInfo, InputStream body) throws Exception {
  String url = uriInfo.getAbsolutePath().toString().replace("/api/", "/internalapi/");
  RestletClientResponse<MyResult> reply = WebClient.put(url, body, MyResult.class);
  RestletUtils.addResponseHeaders(reply.responseHeaders);
  return reply.returnObject;
}

Where WebClient.put is:

public class WebClient {
  public static <T> RestletClientResponse<T> put(String url, Object body, Class<T> returnType) throws Exception {
    Response restletResponse = Response.getCurrent();
    ClientResource resource = new ClientResource(url);
    Representation reply = null;
    try {
      Client timeoutClient = new Client(Protocol.HTTP);
      timeoutClient.setConnectTimeout(30000);
      resource.setNext(timeoutClient);

      reply = resource.put(body, MediaType.APPLICATION_JSON);
      T result = new JacksonConverter().toObject(new JacksonRepresentation<T>(reply, returnType), returnType, resource);

      Status status = resource.getStatus();
      return new RestletClientResponse<T>(result, (Form)resource.getResponseAttributes().get(HeaderConstants.ATTRIBUTE_HEADERS), status);
    } finally {
      if (reply != null) {
        reply.release();
      }
      resource.release();
      Response.setCurrent(restletResponse);
    }
  }
}

and RestletClientResponse<T> is:

public class RestletClientResponse<T> {
  public T returnObject = null;
  public Form responseHeaders = null;
  public Status status = null;

  public RestletClientResponse(T returnObject, Form responseHeaders, Status status) {
    this.returnObject = returnObject;
    this.responseHeaders = responseHeaders;
    this.status = status;
  }
}

and RestletUtils.addResponseHeaders is:

public class RestletUtils {
  public static void addResponseHeader(String key, Object value) {
    Form responseHeaders = (Form)org.restlet.Response.getCurrent().getAttributes().get(HeaderConstants.ATTRIBUTE_HEADERS);
    if (responseHeaders == null) {
      responseHeaders = new Form();
      org.restlet.Response.getCurrent().getAttributes().put(HeaderConstants.ATTRIBUTE_HEADERS, responseHeaders);
    }
    responseHeaders.add(key, value.toString());
  }

  public static void addResponseHeaders(Form responseHeaders) {
    for (String headerKey : responseHeaders.getNames()) {
      RestletUtils.addResponseHeader(headerKey, responseHeaders.getValues(headerKey));
    }
  }
}

The problem is that if the two jars run in the same Java process, then an exception thrown from the internal API is not routed to the JAX-RS exception mapper of the internal API - the exception propagates up to the public API and is translated to the Internal Server Error (500).

Which means I am doing it wrong. So, my question is how do I invoke the internal RESTful API from within the public API implementation given the constraint that both the client and the server may run in the same Java process.

Surely, there are other problems, but I have a feeling that fixing the one I have just described is going to fix others as well.

Answer 1

The problem has nothing to do with the fact that both internal and public JARs are in the same JVM. They are perfectly separated by WebResource.put() method, which creates a new HTTP session. So, an exception in the internal API doesn't propagate to the public API.

The internal server error in the public API is caused by the post-processing mechanism, which interprets the output of the internal API and crashes for some reason. Don't blame the internal API, it is perfectly isolated and can't cause any troubles (even though it's in the same JVM).