Available as of Camel 2.14
Apache Camel offers a REST styled DSL which can be used with Java or XML. The intention is to allow end users to define REST services using a REST style with verbs such as get, post, delete etc.
How it works
The Rest DSL is a facade that builds Rest endpoints as consumers for Camel routes. The actual REST transport is leveraged by using Camel REST components such as Restlet, Spark-rest, and others that has native REST integration.
Components supporting Rest DSL
The following Camel components supports the Rest DSL. See the bottom of this page for how to integrate a component with the Rest DSL.
Rest DSL with Java
To use the Rest DSL in Java then just do as with regular Camel routes by extending the
A simple REST service can be define as follows, where we use rest() to define the services as shown below:
This defines a REST service with the following url mappings:
Notice that in the REST service we route directly to a Camel endpoint using the to(). This is because the Rest DSL has a short-hand for routing directly to an endpoint using to(). An alternative is to embed a Camel route directly using route() - there is such an example further below.
Rest DSL with XML
The REST DSL supports the XML DSL also using either Spring or Blueprint. The example above can be define in XML as shown below:
Using base path
The REST DSL allows to define base path to make the DSL a bit more DRY. For example to define a customer path, we can set the base path in rest("/customer") and then provide the uri templates in the verbs, as shown below:
And using XML DSL it becomes:
The REST DSL will take care of duplicate path separators when using base path and uri templates. In the example above the rest base path ends with a slash ( / ) and the verb starts with a slash ( / ). But Apache Camel will take care of this and remove the duplicated slash.
It is not required to use both base path and uri templates. You can omit the bast path and define the base path and uri template in the verbs only. The example above can be defined as:
Using Dynamic To
Available as of Camel 2.16
And in XML DSL
Embedding Camel routes
Each of the rest service becomes a Camel route, so in the first example we have 2 x get and 1 x post REST service, which each become a Camel route. And we have 2 regular Camel routes, meaning we have 3 + 2 = 5 routes in total.
There are two route modes with the Rest DSL
The first example is using the former with a singular to. And that is why we end up with 3 + 2 = 5 total routes.
The same example could use embedded Camel routes, which is shown below:
In the example above, we are embedding routes directly in the rest service using .route(). Notice we need to use .endRest() to tell Camel where the route ends, so we can go back to the Rest DSL and continue defining REST services.
Configuring route options
In the embedded route you can configure the route settings such as routeId, autoStartup and various other options you can set on routes today.
Managing Rest services
Each of the rest service becomes a Camel route, so in the first example we have 2 x get and 1 x post REST service, which each become a Camel route. This makes it the same from Camel to manage and run these services - as they are just Camel routes. This means any tooling and API today that deals with Camel routes, also work with the REST services.
This means you can use JMX to stop/start routes, and also get the JMX metrics about the routes, such as number of message processed, and their performance statistics.
There is also a Rest Registry JMX MBean that contains a registry of all REST services which has been defined.
Binding to POJOs using
The Rest DSL supports automatic binding json/xml contents to/from POJOs using Camels Data Format. By default the binding mode is off, meaning there is no automatic binding happening for incoming and outgoing messages.
You may want to use binding if you develop POJOs that maps to your REST services request and response types. This allows you as a developer to work with the POJOs in Java code.
The binding modes are:
From Camel 2.14.1 onwards when using camel-jaxb for xml bindings, then you can use the option
To use binding you must include the necessary data formats on the classpath, such as
To enable binding you configure this in Java DSL as shown below
And in XML DSL
When binding is enabled Camel will bind the incoming and outgoing messages automatic, accordingly to the content type of the message. If the message is json, then json binding happens; and so if the message is xml then xml binding happens. The binding happens for incoming and reply messages. The table below summaries what binding occurs for incoming and reply messages.
When using binding you must also configure what POJO type to map to. This is mandatory for incoming messages, and optional for outgoing.
For example to map from xml/json to a pojo class
Notice we use
By having the JAXB annotations the POJO supports both json and xml bindings.
Configuring Rest DSL
The Rest DSL allows to configure the following options using a builder style
For example to configure to use the spark-rest component on port 9091, then we can do as follows
And with XML DSL
You can configure properties on these levels.
You can set multiple options of the same level, so you can can for example configure 2 component options, and 3 endpoint options etc.
Enabling or disabling Jackson JSON features
Available as of Camel 2.15
When using JSON binding you may want to turn specific Jackson features on or off. For example to disable failing on unknown properties (eg json input has a property which cannot be mapped to a POJO) then configure this using the dataFormatProperty as shown below:
You can disable more features by separating the values using comma, such as:
Likewise you can enable features using the enableFeatures such as:
The values that can be used for enabling and disabling features on Jackson are the names of the enums from the following three Jackson classes
The rest configuration is of course also possible using XML DSL
Default CORS headers
Available as of Camel 2.14.1
If CORS is enabled then the follow headers is in use by default. You can configure custom CORS headers which takes precedence over the default value.
Defining a custom error message as-is
If you want to define custom error messages to be sent back to the client with a HTTP error code (eg such as 400, 404 etc.) then from Camel 2.14.1 onwards you just set a header with the key
In this example if the input id is a number that is below 100, we want to send back a custom error message, using the UserErrorService bean, which is implemented as shown:
In the UserErrorService bean we build our custom error message, and set the HTTP error code to 400. This is important, as that tells rest-dsl that this is a custom error message, and the message should not use the output pojo binding (eg would otherwise bind to CountryPojo).
Catching JsonParserException and returning a custom error message
From Camel 2.14.1 onwards you return a custom message as-is (see previous section). So we can leverage this with Camel error handler to catch JsonParserException, handle that exception and build our custom response message. For example to return a HTTP error code 400 with a hardcoded message, we can do as shown below:
Integration a Camel component with Rest DSL
Any Apache Camel component can integrate with the Rest DSL if they can be used as a REST service (eg as a REST consumer in Camel lingo). To integrate with the Rest DSL, then the component should implement the
From Camel 2.16 onwards you can define each parameter fine grained with details such as name, description, data type, parameter type and so on, using the <param>. For example to define the id path parameter you can do as shown below:
And in Java DSL
The body parameter type requires to use body as well for the name. For example a REST PUT operation to create/update an user could be done as:
And in Java DSL
For an example see the