Normally, a RESTful interface in Mule 3.2 is created using the Jersey Module. Adding the Jersey framework to your application may be an overkill for simple RESTful interfaces. Apart from this, Mule and Jersey don’t play well together when you try to move message processing away from Jersey and into Mule. Luckily, the developers at MuleSoft have given us an alternative to Jersey for tackling simple use cases: the Rest Module.
The Rest Module provides a message processor called router that acts as a router as well as a filter. HTTP requests that have their URL path matching the router’s templateURI attribute are routed to one of the router’s child processors depending on the request’s HTTP method. Otherwise, they are ignored by the router.
In the above example, the first router only accepts messages that have a URL path matching the pattern /task/{taskId} pattern such as http://localhost:8080/task/54. GET requests are routed to the get processor’s block whereas POST requests are routed to the post processor’s block. The second router executes the get block only if messages are GET requests and the path equals to /tasks.
URI parameters are copied onto the message’s properties and may be accessed using the variable evaluator. In the example, the expression-transformer puts the taskID parameter in the message payload which is used to query/update the database.
Checkout the Rest Module documentation for installation instructions and the complete list of supported HTTP methods.
Do you know , what happened with this module , it look like the repository was deleted .
Hi Pablo! The doc page was taken down. But you can still download the module from MuleSoft’s Maven repo.
Do you have this sample to download , could you share with the community , don’t you?
Pablo, I don’t understand what MuleSoft is doing. In 3.3 EE the Rest Component has ZERO examples beyond the simplest @GET Resource…nothing at all regarding @POST, @PUT or @DELETE. If you try to follow the Jersey examples, they don’t work in the Mule REST component as a Resource handler, things like @Context annotations throw errors.
So Enter the REST Router, which looks simple enough and fills the need, so MuleSoft yanks it…very frustrating trying to use the REST protocol with an HTTP Endpoint what do you recommend?
It looks like the only choice I have is to write a Java Message Processor after the Http Endpoint to handle the various types after a Choice component on the incoming HTTP methods GET, POST, PUT AND GET. So if that’s all I can do so be it, then why have the &^%$# REST component at all? Its like they are saying “hey we have a Jersey REST component. You are on your own if you want to use it but we have it.”
Claude,
I meant to ask both you and Pablo about this. If you have any suggestions on how to implement REST behind an HTTP endpoint in Mule, I would greatly appreciate it.
Ollie
Ollie, the module is available again on GitHub: https://github.com/mulesoft/mule-module-rest-router
I cannot get the REST Router to work with the lastest version of Mule Studio, and your sample code no longer works either.
Can it possibly be that an ESB does not have a simple way to add a REST server? I’ve spent the day look for any example or documentation, and all I find are broken links. I have the original source to the rest-router but all the schemas are no longer available.
Do you currently have a simple REST service running?
Hi John,
the rest module was updated and the documentation was updated too. Please have a look here: http://mulesoft.github.com/mule-module-rest-router/mule/rest-router-config.html
Hi Alan
The schemas used by that module no longer exist. http://www.mulesoft.org/schema/mule/rest-router/current/mule-rest-router.xsd.
Do you know if it is supported or have the module been dropped?
I cannot get the REST Router to work with the 3.4 of Mule Studio, and your sample code no longer works either.