...
- COmanage is concerned about keeping admin tasks to a minimum (since they'll already be a lot of them), so eg user/pass is easier to manage than SSL certs.
- Possibly, both for Gears (if backsync from the group manager is allowed) and for domesticated Apps.
- REST is good, XML or JSON.
- Gears isn't using SOAP, so would rather not need it.
- Simple probably.
- No opinion.
- No, it's a failure.
- Not needed.
- Probably.
- Isn't this basically the same as #8?
Grouper responses
- Pluggable authentication is ideal. user/pass that delegates to kerberos is needed, also user/pass in http basic auth, at least
- Messaging: This seems like it would be useful, but hasn't taken off that much in Grouper, so we should at least plan for it in the future
- REST? (if REST, then XML, JSON, and/or XHTML): I think we should focus first on the object types that are passed back and forth, and we can see what translations we need to convert that to a plain text HTTPs protocol... this is how Grouper works to support so many formattings
- SOAP: Would prefer to start with REST-like
- Either is fine, though having a replace operation is nice (which takes a list of users)
- Simple responses or complex responses: If there is a "Subject Service"or whatever service to get at the data, then simple responses are fine. It is useful in Grouper to have complex responses, though there is more complexity
- How are results communicated back? Result code, description, warnings, errors, success_TF, etc? I like the grouper model, where there are some HTTP headers, a success T/F, a response code, message, etc
- If you add a member to a group who is already a member, is that a success, and is there a result code that represents that? (same with delete): Operations should definitely be idempotent... if an operation is invoked twice, it should not be a failure (e.g. a client might think there is a timeout and resubmit, then it might get processed twice). However, result codes should be descriptive
- Paging and sorting for results? If this service is used for UI's, then we need it. And if we have it, we definitely need a Subject Service
- Is the client and server version transmitted in the request/response? We should plan for versioning, which includes transmitting the versions back and forth.
- Should operations be idempotent? i.e. if an operation is executed twice, should be a success both times (e.g. add member, create group)