Closed sandervanhooft closed 3 years ago
I'll look into this tomorrow
Problem scope is a bit larger than I thought, will continue this next week.
Most Subresource Endpoints (i.e. CustomerPayment) generate the urls, so any _links
passed in via the parent resource are not being used to pass on the testmode
setting.
testmode
, but _link is not used in subsequent call. This happens when the client itself generates the url to call and the resource mode
setting is not used in the url parameters.testmode
and messes up subsequent url (parameter) parsingmode
attribute to all relevant Resources. Its availability is currently inconsistent.testmode
preset currently work in the client? Is this breaking things? Url should be deconstructed into base url and parameters before other parameters are merged in.testmode
be filtered from input parameters if already appended to the url?oAuthTestmode()
switch on to the client be a cleaner approach?rest_list
rest_create
rest_read
rest_delete
rest_update
Also see #417 .
@willemstuursma Significant impact. Any thoughts? I'll continue work on this this afternoon.
This php client was initially build to mirror all API endpoints, and generate the links itself.
Now, the API is providing urls for subsequent calls, including preset parameters for testmode. Using these provided urls instead of generating them in the client seems to be the preferred way.
I think it's best to distinguish between base resources (i.e. /payments
) and subresources (i.e. /customer/<id>/payments
).
Both of the following options are scattered throughout the client. Best to favour one of these for consistency:
Option A
Option B
Same as A, but for point 2:
For subsequent calls to subresources, generate the url in the client, use the base resource attributes to determine parameters like testmode and merge these with additional parameters. Use direct calls (option A point 3) for this.
@willemstuursma from previous issue discussions it seems you're favouring option A, correct?
I'm personally leaning towards option B as it's closer to the client's original design and less complex (less url/parameter parsing). Then again, I may be missing something.
Closing this for now, let me know if it should be reopened.
Specifications
Describe the issue
Propagating the
testmode
setting to subsequent calls is now dealt with by the Mollie API. Including thetestmode
parameter in subsequent calls is however hardcoded in some places in this client (see here). This may cause some issues.