How to manage HATEOAS links behind a RESTful API Façade

[Antonio de Donato]

Hi All,

This is my first post on this interesting discussion group, so thanks in advance to all of you willing to help :)

I am a bit confused on how I should process hateoas links behind an API façade we're going to expose to our clients.

Basically we have this façade exposing REST APIs to a client; each request is forwarded to Apache Camel, which is used as a middleware to compose the underlying business services. These services are implemented as RESTful web-services, and reply with a response containing both data and hateoas links. The data should be aggregated and used to create the client response into the façade, together with the corresponding hateoas links (we have therefore links from the underlying business services and links provided by the façade to the client). My confusion starts here: how should I manage these links? What responsibility do the façade and the middleware (Apache Camel) have with regards of these links?

I have probably missed some concept and need some guidance :)

Thank you very much,
Antonio

[Jørn Wildt]

It seems to me that your facade is the one who is responsible for the URLs to the various resources it exposes, thus it should also have the responsibility of creating the links itself. I don't see how the subsystem could know how to create URLs when it is the facade that handles them.

If the subsystems have actual resources with links them self and these subsystem resources are accessible from the outside, then I guess you could include the links directly and let the clients talk directly to the subsystems. If, on the other hand, the subsystems are inaccessible to the client, then you need to set up some kind of custom mapping from external facade URLs to internal subsystem URLs (and implement this mapping in the facade system).

/Jørn

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/groups/opt_out.

[Richard Mateosian]

On Thu, Sep 12, 2013 at 11:57 PM, Jørn Wildt <j...@fjeldgruppen.dk> wrote:

If the subsystems have actual resources with links them self and these subsystem resources are accessible from the outside, then I guess you could include the links directly and let the clients talk directly to the subsystems.

Bad idea. The more internal details you commit to, the more problems you create for yourself.

 

If, on the other hand, the subsystems are inaccessible to the client, then you need to set up some kind of custom mapping from external facade URLs to internal subsystem URLs (and implement this mapping in the facade system).

Good idea.  The indirection is inexpensive and gives you a lot of flexibility.   ...RM

--

Richard Mateosian <x...@pacbell.net>
Berkeley, California

[Antonio de Donato]

Hi All,

Thanks for your replies.

I agree with your points, and that's the kind of solution we were putting down. Our API Facade should be designed as a simple interface to a complex system, made of multiple reusable services exposing an API. The service orchestration should be accomplished by means of a middleware which, in our case, is Apache Camel. The facade is a simplified interface to the complexity of the mediation engine and the underlying services.

Considering that the service orchestration is done in Camel, so that it runs business processes in terms of pipes and filters (acting as a sort of lightweight ESB), do you still think the mapping between internal and external URLs should be done in the facade, instead of the middleware? Can they be considered as steps of a business process running in the middleware and started by the facade?

Since we're trying to design a distributed platform that in future will become a "complete" SOA platform, accessible from a public API layer (which can be our current API facade), do you think our approach is valid or it can be simplified/improved further?

Thanks again for your help,
Antonio

[Jørn Wildt]

> Considering that the service orchestration is done in Camel, so that it runs business processes in terms of pipes and filters (acting as a sort of lightweight ESB), do you still think the mapping between internal and external URLs should be done in the facade, instead of the middleware? Can they be considered as steps of a business process running in the middleware and started by the facade?

Sorry, but that is not part of my expertise.

/Jørn

--

[Antonio de Donato]

Hello Jørn,

Thanks anyway for your help :)

Antonio