Here is one more example of how the updated REST client/server libraries
would work. It has one command which can be invoked with a selection of
entity id's, the list of which is provided by the API. This is a typical
"show and select from list" type of thing.
On the server you would have this:
public static class RootResource
extends ContextResource
{
public void commandwithvalue( TestCommand command )
throws Throwable
{
rootContext().commandWithValue( command );
}
public Links commandwithvalue()
{
return new LinksBuilder(module).
command( "commandwithvalue" ).
addLink( "Command ABC","right" ).
addLink( "Command XYZ", "wrong" ).newLinks();
}
}
and the client looks like this:
crc.onResource( new ResultHandler<Resource>()
{
// On refresh, first query "commandwithvalue" to get the list
// of possible links, each of which represents a selection
@Override
public void handleResult( Resource result, ContextResourceClient
client )
{
client.query( "commandwithvalue" );
}
} ).onQuery( "commandwithvalue", Links.class, new ResultHandler<Links>()
{
// Select a link from the list and invoke it
@Override
public void handleResult( Links result, ContextResourceClient client )
{
Link link = LinksUtil.withId( "right", result);
client.command( link );
}
} ).onCommand( "commandwithvalue", new ResponseHandler()
{
// Handle the result
@Override
public void handleResponse( Response response,
ContextResourceClient client )
{
System.out.println( "Done" );
}
} );
// Kick off the use case
crc.refresh();
---
The serverside have two methods with the same name, meaning there is one
query with the name "commandwithvalue" that provides the possible
options for invoking the command "commandwithvalue". The client handles
this by first doing a refresh on the usecase, then asking for the list
of possible options, selecting one and invoking it, and finally handling
the result of that. If anything goes wrong (connection timeout, etc.) it
can restart from the point of "refresh".
The above is I think the by far best way to easily write true REST
API's, as the serverside coding is trivial, and the clientside code
allows for very complex handling of the usecase, including error
handling. From the above server code it should be possible to generate
API documentation automatically as well, which is a bonus.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
