Define our own Request objects instead of reusing the ones from the SDK

[david-at-aws]

Currently we're reusing the Request classes from the SDK as inputs to action methods (and collection getters). This lets you do some weird things like:

User user = iam.getUser("David");

// What does this even mean?
user.delete(new DeleteUserRequest().withUserName("Shuo"));

Ideally we'd be generating our own Request-like classes to hide parameters that will be mapped on automatically by the resource object you pass the request to, avoiding the awkward situation above. The big hurdle is what to call these new classes. XxxRequest is already taken by the SDK (and name conflicts are no fun); everything else I've tried so far looks awkward. There are also cases where we'd ideally want multiple request classes for a single API operation depending on what parameters are going to be automatically mapped, which makes naming even trickier:

interface Vault {
    /**
     * This request object should expose the Completed and StatusCode parameters.
     */
    JobCollection getJobs(ListJobsParameters params);

    /**
     * This request object should not.
     */
    JobCollection getFailedJobs(ListFailedJobsParameters params);

    ...
}

Comment here if you'd like to see this worked on sooner rather than later, or if you have suggestions for naming schemes!

[futurely]

The Request classes are POJOs wrapping the necessary parameters. Is it possible to further simplify? But the manual coding process can be replaced with much faster automatic generation using Apache Thrift/Facebook Swift or something similar.

[david-at-aws]

I've played around with exposing an equivalent of JsonObject instead of strongly-typed request POJOs, but I really like having autocomplete to remind me what the inputs for a particular operation are. Or were you suggesting something in a different direction? I'd love to hear ideas.

The request POJOs from the SDK are automatically generated, and if we end up doing custom request classes for this library we'll certainly generate those as well. I'm currently leaning away from doing so for this library though - there just doesn't seem to be a good way to solve the naming issue, even if we hand-code (much less trying to do so in an automated fashion).