camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Commented] (CAMEL-7354) make it easier to define and expose clean RESTful APIs to back end services / endpoints via a new "rest" endpoint
Date Wed, 16 Jul 2014 15:01:22 GMT


Claus Ibsen commented on CAMEL-7354:

For example we could remove the path and just rely on the verbs
                            .transform(constant("Hello World"))
                            .transform(constant("Bye World"))

> make it easier to define and expose clean RESTful APIs to back end services / endpoints
via a new "rest" endpoint
> -----------------------------------------------------------------------------------------------------------------
>                 Key: CAMEL-7354
>                 URL:
>             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

View raw message