Improve Content Automation to support the EasySOA API

[mkalam-alami]

Planning

1. Define precisely the EasySOA API needs
2. Evaluate if the Content Automation (CA) is appropriate
3. Make the changes to the CA and implement the EasySOA API on top of it

   CA vs EasySOA API

   Opportunities

   • Allows to leverage the numerous existing Nuxeo web services
   • Allows to leverage the future support of CA services in EasySOA (discovery...)
   • Could be a use case for services proxying
   • Eases the use of OAuth?

     Issues/required evolutions

Ease use of CA for "traditional" REST users (i.e. no Java connector but XML/JSON over HTTP requests) by exposing an additional, adapted version of CA°. For that, lessen the "specific taste" of using CA operations (ex. "input"), and more widely allow for more RESTful services°° when it makes sense :

• Get rid of the "envelope" when possible, by directly passing the parameters (no wrapping into a "params" field, no "context" and "input" used for chaining). Ex. "context" or "input" could be looked for within parameters if not provided.
• That allows better use of the HTTP methods (GET/POST/PUT/DELETE). Obviously a big select query can't be provided in the URL so POST will still be required, but small selects could make though it in GET.
• That is resource oriented when possible, ex. adding some GET on the docRef or docPath. Making it also a browsable API would be pretty but not mandatory.

°Among the benefits of this, we can also mention a better integration with an eventual Backbone.js-powered UI. °°Via a proxy?

[tiry]

This is indeed part of the plan for this Year, we'll discuss about that soon.