REST API implementation calls in mule - Jersey vs Plain-Old-Mule-HTTP

I am trying to determine whether to use -

  • Jersey (JAX-RS) with an incoming endpoint based on HTTP.

  • Use an HTTP outbound endpoint, and then examine the HTTP header data (e.g. http.method, http.query.params, http.query.string, etc.) to determine the REST methods. that is, a custom Jersey-based approach for implementing REST.

Benefits of Approach No. 1

  • Standard: A JAX-RS standards-based approach for implementing a leisure service in Java.

  • Documenting is easy: generating documentation is pretty simple because there are many tools that use JAX-RS annotations to create documentation.

The disadvantages of approach number 1

  • If we need to use Jersey in Mule, then the Jersey methods act as a passage 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 case, we must transfer this data to the next stream, where it is either inserted into the database or redirected to another web service. We do not want to enter a special mule code in this class to call other Mule threads from the create method. We have no choice but to transfer the payload from this method and process it in the mule stream.

  • After creating the process creation method in Jersey, a Response object is created that encapsulates the payload. If we want to do something with the payload, we must first extract the payload from the Response object. This is not an easy problem.

Any suggestions, opinions, thoughts?

+6
source share
3 answers

We do not want to introduce special code in this class to call other Mule threads from the create method. We have no choice but to transfer the payload from this method and process it in the mule stream.

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

+2
source

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

The 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 a mule stream that shows how each DBOperations method maps to a different stream in a mule configuration.

 <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> 
+4
source

There is also a third option, if you do not want to bind yourself to Java code - it is a REST Router Module:
http://mulesoft.imtqy.com/mule-module-rest-router/mule/rest-router-config.html
and I think it will be better for you.

What else, a couple of days ago, I wrote an article about REST services on Mule, describing all three of these approaches. Examples are included. This may be useful for 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

+4
source

Source: https://habr.com/ru/post/955932/


All Articles