[
https://issues.apache.org/jira/browse/ACE-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13054396#comment-13054396
]
Marcel Offermans commented on ACE-151:
--------------------------------------
First of all, thanks for the feedback. In short, I like how you guys extended
and detailed the interface. Between Bram's feedback and yours I think we nailed
the main concepts pretty well this way and if nobody else objects (or adds to
it) this is what I'm going to work on.
> Create a REST client API
> ------------------------
>
> Key: ACE-151
> URL: https://issues.apache.org/jira/browse/ACE-151
> Project: Ace
> Issue Type: New Feature
> Reporter: Marcel Offermans
> Assignee: Marcel Offermans
>
> After some discussion on the mailing list, we agreed that it makes sense to
> add a REST based client API to ACE to make it easier to integrate ACE in
> different environments.
> The main requirement for this API is that it should expose the whole client
> API (currently available as OSGi services) using REST. Because each client
> interacts with the server using a local checkout, this probably means some
> means to work on sessions (which might seem like something that's not done in
> REST but in this case a session is like a working area that you create for
> manipulating its contents and finally commit back to the server and clean up.
> Authentication can be added via normal basic authentication, so there's no
> need to explicitly design that into the API.
> So an interaction with the server could start somewhat like this:
> POST /ace/client -> sessionid
> This will trigger a basic authentication, which, if it succeeds, will return
> a session id. It makes sense to also implicitly do a checkout.
> GET /ace/client/mysessionid/feature -> list of feature id's
> Will return a list of features in the repository.
> PUT /ace/client/mysessionid/feature/MyCustomFeature
> Will create a new feature with a unique id called "MyCustomFeature". Maybe
> the put will also contain some (JSON/XML) data to describe the feature.
> In general, we can map all our entities (artifacts, features, distributions
> and targets) as well as all our associations (artifact2feature,
> feature2distribution, distribution2target) to REST endpoints that are very
> similar, so:
> /ace/client/<sessionid>
> /artifact
> /feature
> ...
> And for each of those repository objects (as they're called in the code) we
> can do things like:
> GET /ace/client/<sessionid>/<repositoryobjecttype>/<objectid>/tag
> To get a list of all tags associated with object "objectid".
> PUT /ace/client/<sessionid>/<repositoryobjecttype>/<objectid>/tag/description
> "This is a description."
> To set/replace the description tag.
> Finally, for the 'checkout', 'revert' and 'commit' commands, we could do
> something like this:
> GET /ace/client/<sessionid>/{commit,revert,update}
> Which will return success or failure.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
