Grouper Developers Forum

[Chris Hyzer <>]

Thanks for the in depth response Gary!

Some discussion topics for today:

> My understanding of the REST approach is that it advocates using PUT,
> GET,
> POST and DELETE for Create, Retrieve, Update and Delete (CRUD).

I don't really prefer this approach, but I hear what you are saying.  I think 
REST should be over HTTP just like web programming is (where GET and POST are 
generally used), so we can discuss

> considered a PUT - which would presumably take some actual XML as
> input?

The non-simple operation takes XML, the simple one just takes url params

> Subsequently, I would expect a response of XML which would give an
> overall
> status for the operation, and, perhaps, individual responses for each
> subject if there were an error, and possibly the uuids of the resulting
> objects - or the objects themselves coded in XML?

The non-simple one returns XML, the simple one is just a string, but that 
should be XML I agree, I will change it

> I'm not sure that the Group lookup is quite right. I would expect the
> lookup to happen in a separate call so that the client then has a
> specific
> Group uuid or name to pass to addMember. extensions should be unique

Name isn't unique for a group, right?  Does name contain all stems?

> within a stem but not between different stems so the lookups could retrieve
> 1
> Group. Stems can be nested to any level. You have
> &groupStemExtensions=stem1:stem2 which I would take as stem2 being a
> child
> of stem1 whereas wsGroupLookup.setStemExtensions(new String[]{"stem1",
> "stem2", "stem3"}); implies separate stems in which you lookup the
> 'query'
> extension?

These were supposed to be the same... both have several parent stems.  I will 
add uuid to the group finder, and people can lookup the group if they like, 
or use the finder with a unique id to save a step.  Reducing the number of 
web service calls is paramount to achieve good performance and scalability.

> As indicated above, for REST I would expect an XML response rather than
> something SOAP specific.

Just to clarify, there is never anything SOAP specific in REST in Axis2 or 
what I am doing.  I don't know what happens in Axis2 when an exception is 
thrown, but it wouldn't be a SOAP fault

> There is a Group query system based on GrouperQuery which uses
> QueryFilters
> to construct complex queries. GroupFinder has a findByAttribute method
> which could search on extension - but is likely to do a case-
> insensitive
> substring search. I think we need to discuss Group lookup on the call

OK, just unclear as to whether I need to lookup each stem in the hierarchy 
until the parent one, then the group, or if that already exists


> Actually the API does allow it. If you change a Stem extension all
> descendant stems and groups have their names changed - which could take
> quite a long time in some cases. In fact, I've found in loader scripts
> that
> you need to be really careful not to use setExtension or
> setDisplayExtension on Stems unless you are really changing the value!

OK, just not clear about what all terms are.  The group name contains all the 
stem extensions?  That makes it easy.


> If a batch method is added to the API I would suggest
> grouper.properties.
> It raises the question of whether there ought to be an appropriate
> 'query
> method so clients can determine the maximum allowed

Yeah, in certain operations the client should specify the max

> > 6. Subject search: - id vs identifier?  which to use?
> Probably ought to allow either. In addition to:
>   subjectLookups[0].setSubjectId("abc");
> have
>   subjectLookups[0].setSubjectIdentifier("xyz");
> They could be mutually exclusive i.e throw an exception if the other
> has
> been called, or use id in preference if both set.

Actually, I want to know what the difference is.  In the Javadoc it is not 
explained what the difference between subject id and identifier is.

> > 7. Transactions: - how should they work, or should a param specify?
> i.e.
> > if any fail should all fail, or just the one that failed?
> Probably have a param specify. Currently the API is likely to throw an
> Exception if the Subject is already an immediate member of a group. We
> may
> not want a batch to fail because of that.

Good catch.  I agree the client needs to specify this as well...

Thanks!
Chris