-
Notifications
You must be signed in to change notification settings - Fork 555
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
Make request ID and response information available on all API calls #492
Conversation
def self.card_error(error, resp, error_obj) | ||
CardError.new(error[:message], error[:param], error[:code], | ||
resp.code, resp.body, error_obj, resp.headers) | ||
end |
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.
These helper methods to create errors are a layer of obfuscation and don't add much, so I removed most of them (general_api_error
survived because it's called more than once).
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.
OK, +1
@@ -12,7 +12,7 @@ def request(method, url, params={}, opts={}) | |||
api_base = headers.delete(:api_base) | |||
# Assume all remaining opts must be headers | |||
|
|||
response, opts[:api_key] = Stripe.request(method, url, api_key, params, headers, api_base) | |||
resp, opts[:api_key] = Stripe.request(method, url, api_key, params, headers, api_base) |
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.
These are nitpicky changes, but I tried to call all local variables containing a StripeResponse
"resp
" for global consistency.
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.
👍
attr_reader :http_body | ||
attr_reader :http_headers | ||
attr_reader :http_status | ||
attr_reader :json_body # equivalent to #data |
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'm thinking it might be a good idea to deprecate the use of these fields and make them pass throughs to response
in the meantime, but I deferred that for the time being.
# | ||
# Note: We should try to move away from the very heavy constructors ordered | ||
# parameters to each just setting accessor values directly or optional | ||
# arguments. |
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'd like to change this constructor to just take two arguments: (message, resp)
for cleanliness, but I figure that people might be instantiating errors in their test suites (even though they're not technically part of the public API), so I figured I'd wait until the next major version increment.
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, that makes sense to me. I would change the signature of this constructor at the same time as removing the duplicated fields above (and just use :response)
case resp | ||
# * +response+ - An object containing information about the API response | ||
# that produced the data which is hydrating the StripeObject. | ||
def self.convert_to_stripe_object(data, opts, other_opts = {}) |
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.
Ugh, this should be an optional argument (just have response
instead of other_opts
), but it breaks the 1.9 build. I wonder if we should just rip off that band-aid.
@@ -2,6 +2,13 @@ module Stripe | |||
class APIResource < StripeObject | |||
include Stripe::APIOperations::Request | |||
|
|||
# Response contains a structure that has some basic information about the |
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.
Instead of a structure can you say StripeResponse?
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.
Yep! Done.
# StripeResponse encapsulates some vitals of a response that came back from | ||
# the Stripe API. | ||
class StripeResponse | ||
# The data contained by the HTTP body of the response deserialized from |
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.
Thanks for the great comments on all these!
subscription | ||
end | ||
|
||
def delete_discount | ||
_, opts = request(:delete, discount_url) | ||
self.response, opts = request(:delete, discount_url) |
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.
Nit: this looks to be unused so you could just leave as _
.
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.
Sorry, this one is a little confusing, but we're actually setting self.response
which is an instance-level variable. So after you've deleted the discount object, you can still get the latest response information on the resource.
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.
Oops, duh!
@@ -3,12 +3,24 @@ module Stripe | |||
# errors derive. | |||
class StripeError < StandardError | |||
attr_reader :message | |||
attr_reader :http_status | |||
|
|||
# Response contains a structure that has some basic information about the |
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 might reference StripeResponse here again by name just for clarity
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.
+1. Done.
Thanks for this, @brandur! The change seems pretty clean to me-- it makes sense to have this available whenever a request is made. Just some really minor comments, otherwise: LGTM |
Thanks! And thank you for taking a look at this stuff too. |
Wow, after thinking about it for the weekend, I think we can do better than this interface, and possibly also address #313 at the same time. I'm going to build one more prototype before pulling this in. |
Closing in favor of #498. Most of the commits here are there as well. |
It's currently possible to access a Stripe request ID value from a
StripeError
object, but it's also quite useful to be able to access one from any API call for logging and other purposes. This patch adds aresponse
access toAPIResource
,ListObject
, andStripeError
which includes response information including the request ID.So for any API call it's now possible to do this:
Or on error, the recommended approach is to now access
#request_id
in the same way:Only top level resources are given a
response
value, so we get anil
back for this operation:Fixes #484.
r? @dpetrovics-stripe This one is pretty big, but would you mind reviewing? We could also kick it to someone else on the team if you're pretty swamped right now. Thanks!