[
https://issues.apache.org/jira/browse/CAMEL-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14045797#comment-14045797
]
Claus Ibsen commented on CAMEL-7354:
------------------------------------
Okay got a bit working. I started with a traditional Camel component, so you
can do
{code}
public class CamelSparkTest extends CamelTestSupport {
@Test
public void testSparkGet() throws Exception {
getMockEndpoint("mock:foo").expectedMessageCount(1);
String out = template.requestBody("http://0.0.0.0:4567/hello", null,
String.class);
assertEquals("Bye World", out);
assertMockEndpointsSatisfied();
}
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
from("spark:get:hello")
.to("mock:foo")
.transform().constant("Bye World");
}
};
}
}
{code}
Will work on the DSL later.
Mind that Spark requires Java8 at runtime. And its currently tied to Jetty, so
we would need to add our own transport adapter, as Spark should support that
too. Though it has a bit singleton/static builder stuff, so maybe we need a bit
more work to isolate this better in case ppl run in OSGi with isolated bundles.
> make it easier to define and expose clean RESTful APIs to back end services /
> endpoints via a new "rest" endpoint
> -----------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-7354
> URL: https://issues.apache.org/jira/browse/CAMEL-7354
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
> Reporter: james strachan
> Assignee: Claus Ibsen
> Fix For: 2.14.0, Future
>
>
> All the current HTTP-like endpoints tend to have host/port in the URI and are
> not that DRY; plus there's no easy way to view the API if the consumer of the
> REST API is a REST developer (rather than Java/Camel developer).
> It'd be nice to make things more DRY to have an easy way to define mappings
> from restful operations and URI templates to camel routes.
> Exposing camel routes and endpoints as nice clean RESTful APIs is going to
> get more common (as an alternative to doing things by hand in pure Java with
> JAX-RS for example). Particularly in the age of BaaS and API Management; its
> going to be really handy to use Camel as a facade to wrap back end services
> as clean RESTful APIs.
> So it'd be nice to be able to do things like...
> {code}
> from("rest:get://customers").to(...);
> from("rest:put://customer/{id}").to(...);
> {code}
> i.e. define a rest component which can be configured with a HTTP plugin to
> use (e.g. use netty by default, or be able to reuse the servlet/http engine
> in tomcat/karaf) along with configuring the host/port if not using the
> current containers web connector.
> Then the remaining URI format is HTTP method (GET/PUT/POST/DELETE/OPTION etc)
> followed by a URI template. Optional parameters could be to set content type
> and the like. The Camel DSL can be used to do content based routing and so
> forth.
> It might be even cooler to add a little RestRouteBuilder class which extends
> RouteBuilder to add extra Java DSL operations....
> {code}
> public class MyRouteBuilder extends RestRouteBuilder {
> protected void configure() {
> get("/customers").to(...);
> put("/customers/{id}").to(...);
>
> // the above is just a facade over from("get:/" + uriTemplate) etc
> }
> }
> {code}
> When using URI templates the values (such as 'id' in the examples above)
> should be exposed as properties so they can be referred to in any expressions
> and so forth in the camel DSL.
> Extra brownie points if by default the REST component also exposed a WADL /
> Swagger file listing all the RESTful operations defined on the endpoint; so
> the API can be easily introspected.
> Since JSON / XML are going to be the most common stuff; it might be good if
> the REST endpoint defaulted to using those out of the box if nothing's
> specified. Or at least if something like this were used in the Java DSL...
> {code}
> public class MyRouteBuilder extends RestRouteBuilder {
> protected void configure() {
> put("/customers/{id}", MyDTO.class).to(...);
> }
> }
> {code}
> it'd default to unmarshalling/marshalling using jackson / JSON by default
> (the Binding could be configured on the REST component - or via the DSL on a
> per endpoint basis; but doing JSON / jackson by default seems the most useful
> out of the box)
--
This message was sent by Atlassian JIRA
(v6.2#6252)