...
- 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)
Rice responses
NAU responses
- user/pass in https is what we use.
- ?
- REST is fine.
- Not necessary.
- It depends on the kind of call. In a user interface, add/mod/delete of groups is usually one at a time, so can be simple. Member management is usually many at a time so should be batched. Not sure what is meant by "can you pass a TX".
- Complex. Maybe an option to return simple or complex info on per call basis.
- Prefer errors and warnings with code and description. Success can be a simple code.
- It is a success, but there should be info returned to reflect the difference (i.e different result code from success, not already a member). The more granular the return info is, the better. The user can decide whether the difference is relevant to their application.
- Paging not necessary as part of the interface. Paging needs seem very application-specific. Sorting not necessary, but would be nice if sort field can be specified (e.g. group id vs group name vs other group attribute).
- Don't have a need for it now.
- Yes, but result code should reflect any differences per 8.