Group HTTP JSON API
Note: These operations are easy to call but not to have the expense and limitations of strict RESTful, so that the APIs are easy to understand and access, and not bound to a particular implementation's model. Authentication is at the HTTP layer and not discussed here.
This document assumes JSON, however XML-based documents are easy to envision.
Basically the thought is there is a direct translation between the RPC spec and the web service spec
Why this instead of RESTful?
- It will save everyone time=money if we can have an automatic translation between the structs/rpc and the data formats/transports. We will probably eventually have more than one format (e.g. SOAP and non-SOAP, XML and JSON, etc)
- REST doesn't do as great with lookup things not by one id (e.g. if you want to lookup by id, or uri, or a composite (with subjects, subjectSource and subjectId)
- Not all HTTP clients can do all HTTP methods PUT/DELETE/PATCH/etc, and even all return codes. i.e. is a 500 an error with the fifer server itself, or a validation problem with the inputs?
hasMember
Determine if a subject is a member of a group.
Request Format
Method |
Doesnt matter (probably GET or POST) |
---|---|
URL |
/fifer/groupHasMember/groupLookup_groupUri/<groupUri>/subjectLookup_subjectIdOrIdentifier/<memberId>[?immediacy=<immediacy>] |
URL alternate |
/fifer/groupHasMember?groupLookup_groupUri=<groupUri>&subjectLookup_subjectIdOrIdentifier=<memberId>[&immediacy=<immediacy>] |
Request Body |
None |
Response Format
HTTP Status |
Response Body |
Description |
---|---|---|
200 OK |
SubjectID Document would mimic the RPC response {groupHasMemberResponse: { hasMember: true, responseMetadata: { serverType: "FIFER Java", requestId: "1234567890abcdef1234567890", serverVersion: "1.0.0.0", protocolVersion: "1.0.0.0", success: true, resultCode: "SUCCESS_HAS_IMMEDIATE" serverMillis: 345 } } } |
Member Found |