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
While reviewing the issues, I noticed that I have already added issue 32 on the google doc to the first draft. However, this issue was not yet agreed, it was only agreed to make a github proposal first.
I will off course remove this from the API if needed!
But I still think it's a logical improvement to the API that we'd better add.
Any thoughts on this?
As reference, below is a literal copy of google doc issue 32:
Options argument: remove struct rspec_version from it, and instead add that as fixed argument -- it seems to be mandatory, maybe it is better then to move it, proposal throughgithub
Wim:
Context: All AMv3 API calls have options as last argument.
The ListResources, Describe and Provision call all have a mandatory option: struct rspec_version. This option is used to specify the rspec version that the client would like to receive in the result. This is (if I am not mistaken) the only option that is required.
Proposal: remove the current option struct rspec_version from the options argument, and move it to a required direct argument.
Some examples:
struct Describe(string urns[], struct credentials[],
Reason: struct rspec_version is the only option that is required, all other are optional. So why not make struct rspec_version a normal argument instead? That way, only truly optional parameters will be in the option argument, and all mandatory parameters will be direct arguments.
Note: if there are any other mandatory parameters in options, they should also be made direct arguments. If there are any optional direct arguments, they should be moved to options
The text was updated successfully, but these errors were encountered:
While reviewing the issues, I noticed that I have already added issue 32 on the google doc to the first draft. However, this issue was not yet agreed, it was only agreed to make a github proposal first.
I will off course remove this from the API if needed!
But I still think it's a logical improvement to the API that we'd better add.
Any thoughts on this?
As reference, below is a literal copy of google doc issue 32:
The text was updated successfully, but these errors were encountered: