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

Add put functionality to Oauth2 Client #30

Merged
merged 4 commits into from
Jul 12, 2024
Merged

Conversation

kylevillegas93
Copy link
Contributor

Description

  • This change adds a put function to the Oauth2Client
  • I want to use this client with XML, thus I am not coupling this method to json.

Testing

make unit

"""
Issue an HTTP PUT on the given request_path
"""
return self._do_http_method('PUT', request_path, **kwargs)
Copy link
Member

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 pass None 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 in patch and post, obligating integrations to pass it in kwargs. This would be a breaking change.
    Thoughts, @charmingduchess ?

Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

@kylevillegas93 kylevillegas93 requested a review from nonword July 12, 2024 19:12
@kylevillegas93 kylevillegas93 merged commit 4425132 into main Jul 12, 2024
2 checks passed
@kylevillegas93 kylevillegas93 deleted the kyle/oauth2-client-put branch July 15, 2024 18:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants