> + > +To parse the response, jclouds uses [domain > classes](https://github.com/jclouds/jclouds/blob/master/apis/openstack-trove/src/main/java/org/jclouds/openstack/trove/v1/domain/User.java) > to represent the JSON data returned by the service. The array of "users" is > unwrapped into individual User domain objects. Conversely, when creating > users, domain objects are transformed into a JSON request body. > + > +Because of the relative simplicity of user creation in trove, jclouds > developers can use a create method in the features package without having to > build an instance of the User class. For example, the developer might use a > method such as > + > +{% highlight Java %} > +boolean create(String userName, String password, String databaseName); > +{% endhighlight %} > + > +In this case, it was easy to add support for this call by using a [map > binder](https://github.com/jclouds/jclouds/blob/master/apis/openstack-trove/src/main/java/org/jclouds/openstack/trove/v1/binders/BindCreateUserToJson.java). > + > +However, some APIs send or receive significantly more complex JSON > structures. Recent work on Neutron has shown that there are benefits to > increased consistency among the domain classes and the OpenStack API calls > that use them. > + > +Current implementations have the following two issues : > + > +1. Heavy use of map-binders and parsers to transform JSON. Map-binders use > annotation-selected classes to map method data (such as the data in the > create-user call above) to the JSON required by the service. The > [parsers](https://github.com/jclouds/jclouds-labs-openstack/blob/master/openstack-neutron/src/main/java/org/jclouds/openstack/neutron/v2_0/functions/ParseNetworkDetails.java) > apply the reverse transformation: from JSON to domain objects.
[minor] Too many spaces between "use" and "annotation-selected" --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-site/pull/124/files#r17126267
