ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram de Kruijff <>
Subject Re: [jira] [Created] (ACE-151) Create a REST client API
Date Mon, 20 Jun 2011 15:21:48 GMT
Hi Marcel,

On Mon, Jun 20, 2011 at 12:52 PM, Marcel Offermans (JIRA)
<> wrote:
> Create a REST client API
> ------------------------
>                 Key: ACE-151
>                 URL:
>             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.

Sound about right me thinks :) I was going through the your
description and the code to get an idea of how this would work. Some
questions and comments:

> 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.

Should probably return full url not just id (and provide location
through 301) for nice hateoas
Does vaadin client at this point uses one session not bound to user or
is getNewApplication invoked for every new jsession?
Premature performance/resource concerns: Does the current impl scale
up to large repositories and many sessions?

> GET /ace/client/mysessionid/feature -> list of feature id's
> Will return a list of features in the repository.

In general there is no id on RepositoryObject in the model? How would
you map this? Eg. for associations?

> 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.

The this id is the getNameI()? Are there restrictions imposed/assumed on names?
Would prob be nice to support both xml and json. See you already use
xstream could we easily reuse the mapping? For json gson might be a
nice fit.

> 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
> 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.

Why go beyond a resource per entity type? Ease of use and/or performance?

> Finally, for the 'checkout', 'revert' and 'commit' commands, we could do something like
> GET /ace/client/<sessionid>/{commit,revert,update}
> Which will return success or failure.

Guess that so be a PUT of some sort with GET being idempotent and all.

Anyhow, a nice exercise in getting to know the ace model  for now. Let
me know if I can help out somehow.


> --
> This message is automatically generated by JIRA.
> For more information on JIRA, see:

View raw message