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

Support for idempotent requests. #129

Open
thedodd opened this issue Mar 9, 2020 · 2 comments
Open

Support for idempotent requests. #129

thedodd opened this issue Mar 9, 2020 · 2 comments

Comments

@thedodd
Copy link
Contributor

thedodd commented Mar 9, 2020

Per the docs here https://stripe.com/docs/api/idempotent_requests, it would be quite nice if the various API interaction methods supported a way to set this header. There are a few different ways this value could be set. Method param. Constructor pattern for the requests. We should be able to find a solid path forward.

Hard requirements:

  • the value of the Idempotency-Key must be controlled/set by the user.
@kestred
Copy link
Collaborator

kestred commented Apr 13, 2020

Up to this point the library has used the Headers struct to represent similar patterns (e.g. Stripe-Account)

Also see the comment I added #130.

@erichCompSci
Copy link

erichCompSci commented Jan 22, 2022

Hi, in a downstream repo (the async stripe) I've provided an implementation for this by forcing all post requests to take an optional value. That way you can determine if you want this particular header or not per request. This is a significant API change, and it does require changing the generation code.

I know this is a wanted feature. I can not actively support both the non-async code and the async code, but I am willing to discuss this and figure out a common interface and make the changes as necessary.

The biggest problem with adding this to the header struct is that it kind of forces this to be decided per Stripe connection, which means one Stripe connection per API request for different Idempotency calls. That is...a bad idea in my humble opinion.

Adding on an optional idempotency request is another way to go about it, but requires a lot of changes. Alternatively, we could add a new method to all post requests that had an Idempotent string. So instead of just create and update you would have create, create_with_idempotent_key and update and update_with_idempotent_key. That would be backward compatible.

I should also note that we made some changes to the downstream code generation, so if you haven't absorbed them, I can only get you halfway there with the changes. Mostly just looking for the conversation around this feature so that we could start discussing this feature in earnest. I am using this feature right now and will support.

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

No branches or pull requests

3 participants