-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add put functionality to Oauth2 Client #30
Conversation
""" | ||
Issue an HTTP PUT on the given request_path | ||
""" | ||
return self._do_http_method('PUT', request_path, **kwargs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally the put
method wouldn't have a different signature than the other method sigs. In order to support sending non-json payloads (which I assume you intend to do via kwargs['data']
?), we have some options to consider:
- Implement
put
using standard signature (i.e.put(self, request_path, json, **kwargs)
and your integration may be able to just passNone
as second arg? The client would still be json-inclined, but support this as a workaround for sending non-json payloads - Or we change the standard signature declaring
json
as a required second arg inpatch
andpost
, obligating integrations to pass it inkwargs
. This would be a breaking change.
Thoughts, @charmingduchess ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinkin something similar, but it's also not completely clear to me what the scope / purpose of this class is. It's named like a generic oauth2 client, but it seems to have some platform api specific implementation details / functionality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah naming things is hard. We would have called it PlatformApiClient, but we also use it for interacting with Sierra, which makes similar auth and payload choices. The uniting theme (and only real convenience provided by use of this client) is it does the oauth2 auth for you - hence the name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense - I'm aligned with keeping the method signatures the same and maybe we can revisit changing the standard signature later on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea I was going to say the same thing. I think the signatures should match. Maybe for a major release we can reconsider the favoring of json. But for now let's keep the signatures the same.
Description
Testing
make unit