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, 27 Jun 2011 10:10:39 GMT
Hi Marcel,

I like the revised proposal on the wiki. Below just two minor comments
in response to yours.

What I am wondering about is how you will implement this. The current
ACE approach seems a basic servlet that directly hooks into the http
service whiteboard. In Amdatu we also provide a Wink based bridge that
allows you to simply publish a JAX-RS annotated service. Either way,
from an Amdatu standpoint, we need a way to integrate such a component
into the muilti-tenant model. So probably more a discussion for the
Amdatu list, but just curious how you plan to implement this in ACE :)

On Thu, Jun 23, 2011 at 5:49 PM, Marcel Offermans
<> wrote:
> Hello Bram,
> On 20 Jun 2011, at 17:21 , Bram de Kruijff wrote:
>> On Mon, Jun 20, 2011 at 12:52 PM, Marcel Offermans (JIRA)
>> <> wrote:
>>> 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
> My idea was that this could just as well be a relative URL (just like you can have those
in an HTML page), but maybe in this case (the POST request that creates something new) it
makes sense to return a full URL (when GETting long lists of items, relative URLs sound a
lot more appealing to me).

HTTP spec wise the location header must be absolute (although most
browsers will happily accept relative as well). From a HATEOAS
standpoint I think it's a preference thing. Keeping URI construction
on the server make stuff more robust and flexible. On the other hand
you'll have to account for infrastructure that has to rewrite etc. An
alternative approach is adding an xml:base construct to the
representation. Anyway, in the end I think for the ACE use case it
does not make much difference.

>> Does vaadin client at this point uses one session not bound to user or
>> is getNewApplication invoked for every new jsession?
> In Vaadin, the Application IS the session (ie, you're not exposed to web sessions, you
can assume each application is a session). That's not bound to a user (in fact, probably most
Vaadin applications don't even have the notion of a logged in user).
>> Premature performance/resource concerns: Does the current impl scale
>> up to large repositories and many sessions?
> I can only give you a premature answer here, and that is that various people tried out
Vaadin with large numbers of sessions and found no fundamental issues with it.
> We did not test that yet, and to be honest, I don't expect a lot of concurrent users
to manipulate a single repository. Typically that might be the task of only a handful of people.
>>> 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?
> Correct. In fact, in some places, our handling was even a bit inconsistent. Karl just
fixed an issue in that area, see ACE-149.
>> How would you map this? Eg. for associations?
> We will have to come up with some kind of identity for associations. Probably these will
be little more than a unique ID. In the OSGi service API we just use instances so there we
avoid the issue. We might have to revisit that a bit.
>>> 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()?
> Yes.
>> Are there restrictions imposed/assumed on names?
> Names are used in OSGi filter conditions, and should be unique. We'll have to URL encode
them for REST I guess.
>> 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.
> I'm not sure if we want to make the way we map our entities to XML part of the public
API. I'll take a look at gson, but can you explain why you would use it here over the many
other json libraries out there?

To be honest I cannot really compare. I've used gson many times. It's
flexible, lightweight, optimized pretty well and has no dependencies.
Other then that there may be many framework providing the same or

>>> 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.
>> Why go beyond a resource per entity type? Ease of use and/or performance?
> Hmm, maybe you're right here, I don't think it makes much sense to do that.
>>> 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.
>> Guess that so be a PUT of some sort with GET being idempotent and all.
> I think Angelo and Karl had some feedback on this as well (I'll reply to that one next).
>> Anyhow, a nice exercise in getting to know the ace model  for now. Let
>> me know if I can help out somehow.
> I think you just did! :) Seriously, after the design discussions on this have died down,
I'll have a go at implementing this. Feel free to jump in there at any time. And thanks so
> Greetings, Marcel


View raw message