Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] Re: [comanage-dev] Re: Grouper for COmanage

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] Re: [comanage-dev] Re: Grouper for COmanage

Chronological Thread 
  • From: Chris Hyzer <>
  • To: Tom Barton <>, Scotty Logan <>
  • Cc: Digant C Kasundra <>, comanage-dev <>, Grouper Dev <>
  • Subject: RE: [grouper-dev] Re: [comanage-dev] Re: Grouper for COmanage
  • Date: Wed, 14 Jan 2009 00:11:11 -0500
  • Accept-language: en-US
  • Acceptlanguage: en-US

> > o they use POST for searching (kinda like using UPDATE instead of
> > in SQL)

This is one of my main problems with strict REST. The HTTP methods that
accept bodies are POST and PUT. So how do you search if there are a lot of
params to send (like actAs, complex queries, etc)? You need to send those
settings (optionally) to the service somehow, the most convenient way is with
XML in the body of the request. You could be fine with a body in a GET
request anyway (break the spec), but Jakarta commons HTTP-client is not
(which is what grouper uses). Actually, I believe you can do a GET to
retrieve Grouper data if you have no body to send, or if you have a body you
can POST. All operations are like this. They do the real rest thing, and if
you need to post to it you can no problem. Though my samples might all be
posts which is misleading. It knows by the XML sent that the POST is really
a search.

> > o POST is used to create new entities rather than PUT, even though
> the
> > entities' names are known

Again, you can PUT a new entity I believe

A lot of your other points are differences between real REST and Grouper's
REST: some of them are due to the fact that we have REST and SOAP and favored
re-use over exact adherence to REST.

> >
> >> Second, if you do go for a CLI-based approach, I'm curious what gsh
> >> lacks that would motivate you to write another CLI to grouper. Could
> >> you guys report out about that?

GSH only runs with a direct connection to the DB, and the output is subject
to change (if you are CLI screen-scraping). GrouperClient only needs web
service or LDAP credentials, so it doesn't need to be run by the same people
who manage the Grouper installation, and you can specify the output format
you want (safer for CLI screen scraping)

> The tool uses the SOAP interface... the non-RESTful REST interface was
> too distracting.

One thing about the Grouper SOAP vs REST is that Axis doesn't have a good
backwards compatibility strategy that I know of. So with REST, you should be
able to upgrade to grouper 1.5 and not change your client. With SOAP, if a
service changes that you are using, you might need to run two web services
webapps, one with 1.4 API pointing to 1.5 DB, and one with 1.5 API point to
1.5 DB (unless you have no 1.5 clients, in which case, just install the
former and you are all set). I think this is a big reason that grouperREST
has advantages over grouperSOAP...


Archive powered by MHonArc 2.6.16.

Top of Page