You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 30, 2018. It is now read-only.
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:
Useruser = iam.getUser("David");
// What does this even mean?user.delete(newDeleteUserRequest().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:
interfaceVault {
/** * This request object should expose the Completed and StatusCode parameters. */JobCollectiongetJobs(ListJobsParametersparams);
/** * This request object should not. */JobCollectiongetFailedJobs(ListFailedJobsParametersparams);
...
}
Comment here if you'd like to see this worked on sooner rather than later, or if you have suggestions for naming schemes!
The text was updated successfully, but these errors were encountered:
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.
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).
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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:
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:
Comment here if you'd like to see this worked on sooner rather than later, or if you have suggestions for naming schemes!
The text was updated successfully, but these errors were encountered: