On 10/16/11 18:35 , Mads Enevoldsen wrote:
I like this! That really separates the things nicely: the server defines a
url structure wherein all the use cases are implemented. The client
implements the UI of these use cases agnostic about the actual url
structure.
Do I understand correctly that the rel attribute is the name of the usecase?
There's going to be two cases, as in Streamflow right now: either the
rel points to a use case (i.e. a URL that ends with "/"), or it will
point to a command/query within that use case (e.g. rel "open" -> link
"/open").
In the end, the server library should be able to automatically generate
a documentation page which lists all the "rel" attributes, and if it's a
command/query, display the forms and their parameters. Just by
introspecting code, and sometimes actively invoking methods to get
defaults and such. In other words, the formal documentation of the REST
API will be the list of "rel" attributes and what they mean, and also
the forms and their parameters if applicable.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
