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