Implementing REST API calls in mule - Jersey versus Plain-Old-Mule-HTTP

Question

I am trying to determine whether to use --

1. Jersey (JAX-RS) with HTTP based inbound endpoint.

2. Use HTTP based inbound end-point, and then examine HTTP header data ( like http.method, http.query.params, http.query.string, etc.) to determine the REST methods. i.e. non-Jersey-based custom approach to implement REST.

Advantages of approach #1

1. Standard: JAX-RS standards-based approach for implementing rest service in Java.

2. Documenting Is Easy: Generating the documentation is pretty easy because there are many tools out there which use JAX-RS annotations to generate the documentation.

Disadvantages of approach #1

1. If we have to use Jersey within Mule then the Jersey methods act as pass-through for the payload data. Example-

   @POST
   @Produces(MediaType.APPLICATION_JSON)
   public String create(String jsonPayload) {
       logger.debug("Received and added data :" jasonPayload);
       return jsonPayload;
   

   } In our use case we have to pass this data over to the next flow where it either inserted into database or forwarded to some other Web service. We do not want to inject mule specific code in this class to call other Mule flows from within the create method. We are left with no choice but to pass the payload out of this method and handle it in the mule flow.

2. After Jersey processes create method it creates a Response object that encapsulates the payload. If we want to do something to the payload then we have to first extract the payload from Response object. This is an un-necessary hassle.

Any suggestions, opinions, thoughts ?

Answer 1

Based on feedback from David. Here is how I implemented it --

REST class is TestAPI --

@Path("/test")
public class TestAPI {
private DBOperations dbo;

@POST
@Produces(MediaType.APPLICATION_JSON)
public String create(String jsonPayload) {
    System.out.println("Received and added global attribute :"
            + jsonPayload);
    dbo.create(jsonPayload);
    return jsonPayload;
}

Here is the interface --

public interface DBOperations {

  public String create(String json);
  public String read(String json);
  public String update(String json);
  public String delete(String json);

} 

Here is the mule flow, which shows how each method of DBOperations is mapped to a different flow in the mule config.

<flow name="jersey-rest-flow" doc:name="jersey-rest-flow">
    <http:inbound-endpoint exchange-pattern="request-response"
        host="localhost" port="8100" doc:name="HTTP" />
    <logger message="Message Received - #[payload]" level="INFO"
        doc:name="Logger" />
    <jersey:resources doc:name="REST">
        <component class="com.test.rest.TestAPI">
            <binding interface="com.test.DBOperations"
                method="create">
                <vm:outbound-endpoint exchange-pattern="request-response"
                    path="create-data-vm" />
            </binding>
            <binding interface="com.test.DBOperations"
                method="read">
                <vm:outbound-endpoint exchange-pattern="request-response"
                    path="read-data-vm" />
            </binding>
            <binding interface="com.test.DBOperations"
                method="update">
                <vm:outbound-endpoint exchange-pattern="request-response"
                    path="update-data-vm" />
            </binding>
            <binding interface="com.test.DBOperations"
                method="delete">
                <vm:outbound-endpoint exchange-pattern="request-response"
                    path="delete-data-vm" />
            </binding>
        </component>
    </jersey:resources>
</flow>

Answer 2

There is also a third option, if you don't want to tie yourself to Java code - it's REST Router Module:
http://mulesoft.github.io/mule-module-rest-router/mule/rest-router-config.html
and I think, that it would be a better fit for you.

What's more, couple days ago I have written an article about REST services on Mule, describing all these three approaches. Examples included. It may be helpful to you:
http://poznachowski.blogspot.com/2013/10/exposing-restful-interface-with-mule-pt1.html
http://poznachowski.blogspot.com/2013/10/exposing-restful-interface-with-mule-pt2.html

Answer 3

We do not want to inject mule specific code in this class to call other Mule flows from within the create method. We are left with no choice but to pass the payload out of this method and handle it in the mule flow.

I disagree to this statement: component bindings inject Mule-free custom interface into your own classes. This is the approach I recommend for your use: http://www.mulesoft.org/documentation/display/current/Component+Bindings