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
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
@@ -1,4 +1,7 @@
# Changelog
## v1.1.6 7/12/24
- Add put functionality to Oauth2 Client

## v1.1.5 6/6/24
- Use executemany instead of execute when appropriate in RedshiftClient.execute_transaction

6 changes: 6 additions & 0 deletions src/nypl_py_utils/classes/oauth2_api_client.py
Original file line number Diff line number Diff line change
@@ -76,6 +76,12 @@ def post(self, request_path, json, **kwargs):
kwargs['json'] = json
return self._do_http_method('POST', request_path, **kwargs)

def put(self, request_path, **kwargs):
"""
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.


def patch(self, request_path, json, **kwargs):
"""
Issue an HTTP PATCH on the given request_path with given JSON body
Loading