Subject: Grouper Developers Forum
- From: Chris Hyzer <>
- To: Jim Fox <>, Grouper Dev <>
- Subject: RE: [grouper-dev] re grouper next steps
- Date: Tue, 31 Jul 2012 18:38:40 +0000
- Accept-language: en-US
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
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
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)
Is any easier/intuitive than (possible to do something like this with
Or (possible to do something like this with grouper)
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...
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
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
1) Provides clearly defined group resources and representations.
2) Gains the resiliancy, reliability and scalability of clustered
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.
- [grouper-dev] re grouper next steps, Jim Fox, 07/31/2012
Archive powered by MHonArc 2.6.16.