[
https://issues.apache.org/jira/browse/CAMEL-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14048575#comment-14048575
]
Claus Ibsen commented on CAMEL-7354:
------------------------------------
I renamed camel-spark to camel-spark-rest to avoid confusion with Apache Spark
project.
The component name is then "camel-spark".
> 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
>
>
> 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)
