Grouper Developers Forum

[Jim Fox <>]

Watched the videos.  Did make the present state more clear.  However,

The point to REST is that an application, such as a grouper service,
is composed of specific resources with specific states.  The state of a 
resource can be represented some way, say xml, and passed around the 
internet.  So the entire interaction is:  GET the state of a resource,
PUT the state of a resource, or DELETE the resource.  There's nothing 
else.  No dialogs, no saved state, no RPC.

Our group service has only a few resources:

  - all group information except membership
  - entire membership
  - individual memberships

The 'all group information' was an expedience that hasn't caused us
any difficulties.  Essentually, to update anything other than membership
one GETs the group, changes something in the representation, and PUTs
it back.

We could add resources that are parts of groups, say 'admins', but
that's not been necessary.

The utility of this is that I can send these representation of state
around the internet and easily update another group system.  It's
just a PUT of the resource.

So, I think the definition of a grouper service as resources, states,
and representations is the important thing.  There's no need for
any RPC-like mechanisms nor anything bet GET, PUT, DELETE.

Jim


On Tue, 31 Jul 2012, Chris Hyzer wrote:

> Date: Tue, 31 Jul 2012 11:38:40 -0700
> From: Chris Hyzer 
> <>
> To: Jim Fox 
> <>,
>  Grouper Dev 
> <>
> Subject: RE: [grouper-dev] re grouper next steps
>
> 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