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 support for returning orders #1908

Merged
merged 2 commits into from
Feb 6, 2020

Conversation

cjavilla-stripe
Copy link
Contributor

While deprecated, this is currently available in the API so we should support it.

This is my first time adding a custom method to a service like this where the return type is different than the underlying entity. I.e. returning an order, returns an OrderReturn object, I think I did this right, but could use another set of eyes. Another note, I created OrderReturnItemOptions as a new type because OrderItemOptions has the additional currency field. LMK if that was the wrong move.

r? @remi-stripe
cc @stripe/api-libraries @ob-stripe

Copy link
Contributor

@remi-stripe remi-stripe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks good to me. @cjavilla-stripe did you confirm that we're not missing any field on Order or OrderReturn too? If so, re-assign to ob to do the final review

/// List of items to return.
/// </summary>
[JsonProperty("items")]
public List<OrderReturnItemOptions> Items { get; set; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This naming feels like a new pattern. Usually we don't put the action/word name in the options class. But if we don't here, it conflicts with the one for Create which is the same hash but wit currency on top of it.

@ob-stripe Can you check and confirm that's the right naming scheme?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think so. We're just "lucky" that in most cases the shape is shared between e.g. create and update methods, but more generally we probably shouldn't be sharing parameters, at least until the OpenAPI spec actually gives us that information.

@cjavilla-stripe
Copy link
Contributor Author

Thanks @remi-stripe, I reviewed Order and OrderReturn against the API ref and they have all the fields listed (added some of the doc comments).

r? @ob-stripe Can you take a pass at this one?

Copy link
Contributor

@ob-stripe ob-stripe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

/// List of items to return.
/// </summary>
[JsonProperty("items")]
public List<OrderReturnItemOptions> Items { get; set; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think so. We're just "lucky" that in most cases the shape is shared between e.g. create and update methods, but more generally we probably shouldn't be sharing parameters, at least until the OpenAPI spec actually gives us that information.

@remi-stripe remi-stripe merged commit f13a71a into master Feb 6, 2020
@remi-stripe remi-stripe deleted the cjavilla/add-support-for-returning-orders branch February 6, 2020 00:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants