...
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
|
...
Member Found |