Override this method to convert an incoming Resource Invocation Graph
RIG
into an outgoing Resource Response Graph
RRG
. Edits to the RIG
will be the foundation of
the RRG
returned from this service call. Sample code:
public void handleRequest(RIG rig) {
// if we need to check service parameters we could do it here
//SSWAPResource translatedResource = rig.getTranslatedResource();
// loop over every subject, across all matching graphs
for ( SSWAPSubject translatedSubject : rig.getTranslatedSubjects() ) {
// "translation" maps types and properties in the RIG
// into the vocabulary we understand in the RDG.
// for all objects for which the current subject is already stating a mapping
for ( SSWAPObject sswapObject : translatedSubject.getObjects() ) {
// do something:
// edit object based on the type(s) and property values of the subject
}
// if and as necessary, add additional object mappings to subject
SSWAPObject sswapObject;
try { // if and as appropriate
sswapObject = rig.createObject(new URI("http://mySite.org/someData"));
} catch ( Exception e ) {
sswapObject = rig.createObject(); // a "blank node"
}
// do something:
// edit object based on the type(s) and property values of the subject
// add it to the subject
translatedSubject.addObject(sswapObject);
}
// done
// for testing, you may call getRRG()
// if it throws a validation exception, the RRG will not be returned to the caller;
// on error, the caller will get the original RIG returned unchanged
boolean debugging = false;
if ( debugging ) {
try {
rig.getRRG(); // expensive
} catch ( Exception e ) {
System.err.println("Failed to create a valid RRG:");
rig.serialize(System.err);
}
}
}
Providers should do their best to satisfy the request of the RIG, but
they are not required to be exhaustive. For example, SSWAPObjects should
informatively satisfy the contract of the mapping from a SSWAPSubject,
but they do not need themselves to extend a deep graph of relations. The
decision on how much data to return is left to the provider. Regardless,
what data is returned must satisfy the logical contract of the RDG.
If a request is larger than the provider wishes to satisfy (e.g.,
hundreds or thousands of SSWAPSubjects each requiring database calls),
the provider may satisfy none, a few, or all at its choosing. If the
provider wants to satisfy none--i.e., it handles requests on an
all-or-none basis--and it wants the current state returned as an error to
the client, it may return an HTTP 413 Request Entity Too Large response
code by throwing the runtime exception RequestEntityTooLargeException. In
this case no content (neither RIG nor RRG) is be returned to the client.
If the provider is unable to access data, it should fail silently and allow
the RIG to be returned. If the problem is due to a client error, for
example, a missing URL, then the provider may throw a ClientException
to return an error to the client.
- Specified by:
handleRequest
in class AbstractSSWAPServlet
- Parameters:
rig
- RIG
invoking the service. This RIG
should be edited and will become the basis for the
RRG
returned by the service. Best practice is to
leave most of the RIG
untouched, modifying only
the SSWAPObject
subgraphs.- See Also:
RIG
,
RRG
,
RequestEntityTooLargeException
,
ClientException