ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Offermans (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACE-151) Create a REST client API
Date Fri, 24 Jun 2011 12:15:47 GMT

    [ 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

        

Mime
View raw message