...
- user/pass in https is sufficient, but pluggable would be nice.
- ?
- 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.
uPortal Responses
- We approve of pluggable authentication in general with a decent selection of options.
- Which authentication should we support? SSL cert, ws-auth, user/pass in http basic auth, public key signature in http header, other?
- Not sure we have a need for messaging right now
- Yes, we'd very much want REST support. Either XML or JSON would be fine.
- We'd prefer REST to SOAP.
- Simple calls would be nice to have, but we might want batched support with transactions for larger or more complex operations.
- I think we'll need known response codes for programmatic handling of success and errors, but it would be useful to have a readable description to go along with that.
- Yes, it should be successful, and yes, there should be a code to differentiate these events.
- Yes, paging and sorting would be useful.