Is this committed? -- Niclas
On Tue, Oct 18, 2011 at 4:19 PM, Rickard Öberg <[email protected]> wrote: > 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 > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/6a2pl4j I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
