> +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. > +2. Lack of consistent, concise, and user-friendly way to use domain objects > in create/update/list methods. > + > +In addition to fixing these issues, jclouds wants to provide developers with > some compiler checks and other syntactic sugar (fluent builders), while also > supporting different updating, creating, or listing validation strategies. > + > +We want to > + > +1. Ensure object immutability. > +2. Utilize the fluent builder pattern. > +3. Ensure that "create" objects can only be used for create; update for > update; and listed resources cannot be directly sent back to the service.
This seems to be the most important part in terms of why we need CreateOptions/CreateRequest/whatever. Would it make sense to illustrate what the problem is here by extending the code sample below? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-site/pull/124/files#r17126556
