Grouper Developers Forum

[Chris Hyzer <>]

If you have a free hour, can you watch the 4 (or soon to be 5) training 
videos on using Grouper Web Services (not admin) under architects and 
developers?

https://spaces.internet2.edu/display/groupertrain/Grouper+Training

Hopefully then it will make more sense to you.  I haven't received negative 
feedback on the WS being hard to use, but I do agree that we should have a 
standard API.  I wish REST were more conducive to the operations that I 
envision needed by a groups API.  I think the important thing is HTTPS and 
JSON (or some formatting), not that the URL is the noun and the HTTP method 
is the verb.  Some gaps that I see that make REST awkward for groups are:

1. There is more than one way to refer to objects (UUID, system name, gid?, 
etc), whereas in URLs its nice if there is just one thing like a name
2. Some things have composite keys: e.g. subjects are sourceId+subjectId, or 
sourceId+subjectIdentifier, or just subjectId maybe, again, not conducive to 
URL
3. GET,PUT,POST,DELETE are limiting, and I don't think it is a good idea to 
make up custom methods, and GET can't send a request?  Can all browsers or 
user agents do PUT and DELETE?
4. We have a SOAP RPC based version of grouper WS and it is nice if the 
rest-like and SOAP are the same except for data formatting.  If you 
understand or have implemented one, you can understand / implement both

I don't really see why:

(RESTful add member)
PUT 
https://server.institution.edu/grouper/rest/group/systemName/a:b:c/member/subjectSourceId/person/subjectId/12345

Is any easier/intuitive than (possible to do something like this with 
grouper):
POST 
https://server.institution.edu/grouper/rest?operation=addMemberLite&groupName=a:b:c&sourceId=person&subjectId=12345

Or (possible to do something like this with grouper)
POST https://server.institution.edu/grouper/rest
(body)
{addMemberLiteRequest:{
    groupName:"a:b:c",
    sourceId:"person",
    subjectId:"12345"
  }
}

We have had this discussion when we were talking about the FIFER standard 
API, and all people in the discussion but one thought HTTPS/JSON 
(non-restful) was fine, but Im happy to have the discussion again, and any 
standard is better than none, so whatever direction most people agree with is 
fine with me, though I would be happier if things were more practical rather 
than idealistic...  Another idea we had with FIFER is that the full featured 
API could be HTTPS/JSON, but there could be a RESTful one too which was 
limited (e.g. only used system names to refer to things) that would be in 
line with then RESTful mindset...

Thanks!
Chris

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Jim Fox
Sent: Tuesday, July 31, 2012 1:15 PM
To: Grouper Dev
Subject: [grouper-dev] re grouper next steps


This is not so much of a next step, but more of a proposal related
to how Grouper might more easily achieve the next steps.



The executive summary, lest we encounter an error 413 TLDR.

I'd like to see grouper define and implement a complete groups API,
a RESTful webservice API.  (I know there is some sort of rest api
in grouper, but it doesn't appear very RESTful and I've never been
able to figure it out.)


Details, for the non-executive.


This is motivated by a concern I have for our university's groups
service, which does implement an API.

Groups have permeated every nook and cranny of UW's network, and
usage is increasing all the time.  There seems to be no significant
application that does not rely on our groups service, including
our Shib IdP.  It would be difficult to find, even overnight,
a time when a service outage of several minutes wouldn't in turn
cause outages elsewhere.  It is partly for this reason that the most
commonly requested groups resources are served from a pair of LDAPs,
rather than from the registry.  I am always wary of single points of
failure, and single elements that limit scaling.

Our API has a simpler set of resources than what might be required
for grouper, but it is complete.  All of its resources are exposed.
This means we could very easily maintain a cluster of independent
group systems (our API plus the grouper backend plus maybe an ldap
or two) all kept in sync by RESTful resource messaging.  If we wanted
to upgrade to a new OS, a new grouper, a new database, or all three,
It would be simple matter of bringing up the new service and adding
it to the cluster---risk free!  If an entire cluster member were to
disappear, say Seattle, other cluster members would continue the
groups service uninterrupted.  I think we have some scaling gains
as well, but that's not so clear.  In any case it is a route to a
scaling solution.

The utility of a REST API is well enough understood nowadays that
all websites are trending in that direction---even authn services.
(See Eve Maler's InCommon talk from a couple of weeks ago.)
Grouper should adopt this mindset.

In addition to its joining the 21st century, these are some of
the benefits of grouper's adoption of the API---and the resource
messaging.

1) Provides clearly defined group resources and representations.

2) Gains the resiliancy, reliability and scalability of clustered
    systems.

3) More easily integrate with other applications.

4) Provides for seamless upgrades between major releases.

5) Provides a means for third parties to build GUIs, that interact,
    through AJAX, with the API.

6) Disconnects groups from privileges.  These ought to be separate APIs.

7) Provides an easy means for cooperating grouper installations
    to synchronize selected groups.


My 2 cents.

Jim