Newest XAPI server uses 'topTags' as the canonical name of readable tags; and while 'tags' is still an acceptable alias, it will be removed in near future, so it makes sense to change client to use the proper field name.

User.java and UserField.java do not have accessor for profile questions, which are exposed by service. These need to be added.

Since client uses http-client that is based on non-blocking operations, it would be good to expose functionality with non-blocking methods as well: current methods are blocking to keep API simple, but it should be possible to add alternative methods too.
Such methods have benefit of being easier to parallelize, to allow concurrent calls to be made and often reduce end-to-end latency.

Currently we embed simple custom implementation of OAuth client side code; this because none of existing OAuth libraries supported async http client. Now that async http client is reasonably stable (as well as our OAuth code), it should be possible to generalize OAuth client, carve it out, and contribute to http client for others to use.

Currently API has fixed setting for whether to use http or https (ssl) for access. It should be possible to configure this using NingClientConfig object, defining baseline setting and overrides.

External API supports accessing of 'secondary' data by using notation like 'author.fullName'. Results in this case contain "resources", identified by internal id, so that for example Photo resource has property 'author' with author id; and then "resources" map will have entry with that key, and value(s) (fullName in this case).

Java client does not yet support this style of access; it would be good to add support. Challenges include the fact resources can be of different types (not just User instances but other types in some cases), so data binding needs to be done lazily (deferred, based on access) or at least using custom resolution of type.

Although /Topic resource is support to by xapi service, api client does not yet expose it. Should be easy to add support.

Currently Token creation uses plaintext authentication, but it would be good to also allow use of HMAC (or default to it).