Grouper Developers Forum

[Chris Hyzer <>]

Hey,

 

In the meeting wed, I said I would email about content types.  I sidestepped the issue, you can read about it here if you are interested.

https://wiki.internet2.edu/confluence/display/GrouperWG/Grouper+WS+Lite+-+REST+input+-+output+XHTML+-+XML+-+JSON

 

I committed my current work of web services, things are in a less working state, so you might not want to checkout now.  The only service that is in working order is addMember (for SOAP / REST / Etc).  Here is an example of the documentation.  Notice samples are linked from there.

 

https://wiki.internet2.edu/confluence/display/GrouperWG/Add+Member

 

The most significant thing I have done here is a harness that runs samples, captures HTTP output, stdout, etc, and puts in CVS so we can link.  E.g.

 

http://viewvc.internet2.edu/viewvc.py/grouper-ws/grouper-ws/doc/samples/addMember/WsSampleAddMemberLite_xhtml.txt?root=I2MI&view=co

 

http://viewvc.internet2.edu/viewvc.py/grouper-ws/grouper-ws/doc/samples/addMember/?root=I2MI&pathrev=HEAD

 

Anyways, it should be downhill from here J.  Another change that Tom just confirmed (and I will redo addMember), is the following below (significant change, but maybe Tom and I are the only vocal people on this topic).

 

Will keep you updated as I update the rest of the services…

 

Regards,

Chris

 

#############

Tom,

 

I think it makes sense to make the following changes regarding web services:

 

1.       The REST interface will be full featured (similar to SOAP, maybe not all the operations to start out with, but most, and easily possible to add more)

2.       Do not support/document the XML/HTTP one (the one that Axis gives)

3.       Change all the “simple” operations to be named “Lite” (and have them available in REST and SOAP)

 

This would give the following advantages:

 

1.       People using REST will not be clamoring for more features.  If we restrict trying to make that one Lite, then people will keep nagging about adding things back (e.g. group finder, multiple assignments at once, etc, we weren’t originally planning those, but we are adding).  So the Lite assignment would be one subject one group.  And the non-Lite would be replace the members of a group with a list of subjects.  Both in REST and SOAP.

2.       If there is a full featured way to have the web services without SOAP (as the REST one would be), then I don’t think we need to document/support XML/HTTP.

3.       The “Simple” (non-batched) concept would go away, thus simplifying things.  Along with XML/HTTP going away, the web services will be a lot easier to understand

4.       Grouper-Lite would be available in SOAP or Rest.  I don’t think of Grouper-Lite as implementation specific.  Why should it be limited to REST?  And why should REST not be full featured?  If someone goes down the path of using REST, and bumps up against something they need that isn’t there, they can just use a non-Lite REST operation…  Similarly, is someone is using SOAP, and needs to do a quick and dirty thing, then why not use SOAP-Lite?

5.       Would drastically reduce the complexity of the code/documentation I need to support.  The easiest thing to do is to use the same beans (types) for all the web services.  And if I have Simple ones, and Lite ones, there is redundancy and overlap.  Also, documenting the XML/HTTP is tedious

 

The reasons this is coming up now:

1.       I am seeing how the REST is implemented and seeing overlap

2.       The REST data structures (not URLs) are similar to SOAP, it will not be as hard to go back and forth between them as I had thought (if someone starts with REST and decides to switch to SOAP later on)

3.       Since the REST will support XML and not just XHTML, it will be easy for people to integrate with it (used to be an advantage for XML/HTTP)

 

Think we can discuss this?

 

Thanks!

Chris