Grouper Developers Forum

[Chris Hyzer <>]

> > o they use POST for searching (kinda like using UPDATE instead of
> SELECT
> > 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...

Regards,
Chris