Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restrict API call query parameters to what we say we accept #653

Closed
stephenplusplus opened this issue Jun 10, 2015 · 2 comments
Closed

Restrict API call query parameters to what we say we accept #653

stephenplusplus opened this issue Jun 10, 2015 · 2 comments
Assignees
Labels

Comments

@stephenplusplus
Copy link
Contributor

Related: #647, #652

Right now, we sometimes kind of blindly pass the user's provided object to the API. We should be sure to only pass through what we say in our docs we accept.

I'm thinking something like:

/**
 * @param query.maxResults
 * @param query.pageSize
 */
Service.prototype.method = function(query, callback) {
  var allowedQueryParameters = ['maxResults', 'pageSize'];
  var requestQuery = util.pluck(query, allowedQueryParameters);
  // If `query` had more on it, we get a new object back with just the
  // params we want the API to receive.

  callApi('POST', '/path', requestQuery);
};
@ryanseys
Copy link
Contributor

Interesting idea, I've explored a similar idea before in googleapis with required parameters here, however sometimes there are an outrageous number of different optional parameters that can be passed which is just tedious to document. Additionally, if implemented, this actually wouldn't really solve the problem of us mis-documenting the required parameters and letting something like #647 sneak through because of our human error. Also, this would make non-breaking additional parameters added to the API silently (which Google likes to do from time to time) effectively refuse that functionality. Yes that'd be good as long as the user files a bug and we fix it, but its still scary to the user when they are doing the right thing and we aren't.

@stephenplusplus
Copy link
Contributor Author

Okay, let's do it the way we're doing it. 👍

Will close, anyone feel free to re-open if there's a better solution than "nevermind" :)

sofisl added a commit that referenced this issue Nov 11, 2022
PiperOrigin-RevId: 322420178

Source-Author: Google APIs <noreply@google.com>
Source-Date: Tue Jul 21 12:43:47 2020 -0700
Source-Repo: googleapis/googleapis
Source-Sha: be0c5a9b1b88ca3bb8ad993ae7b2e6affde7fee2
Source-Link: googleapis/googleapis@be0c5a9

Co-authored-by: sofisl <55454395+sofisl@users.noreply.github.com>
sofisl pushed a commit that referenced this issue Nov 11, 2022
sofisl pushed a commit that referenced this issue Jan 24, 2023
This PR was generated using Autosynth. 🌈

Synth log will be available here:
https://source.cloud.google.com/results/invocations/5c526dd9-97ec-4177-a349-428900ed8fb2/targets

- [ ] To automatically regenerate this PR, check this box.

Source-Link: googleapis/synthtool@079dcce
sofisl pushed a commit that referenced this issue Jan 25, 2023
This PR was generated using Autosynth. 🌈

Synth log will be available here:
https://source.cloud.google.com/results/invocations/5c526dd9-97ec-4177-a349-428900ed8fb2/targets

- [ ] To automatically regenerate this PR, check this box.

Source-Link: googleapis/synthtool@079dcce
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants