Testmode in _links: impact

[sandervanhooft]

Specifications

• API Version: 2

Describe the issue

Propagating the testmode setting to subsequent calls is now dealt with by the Mollie API. Including the testmode parameter in subsequent calls is however hardcoded in some places in this client (see here). This may cause some issues.

[sandervanhooft]

I'll look into this tomorrow

[sandervanhooft]

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.

[sandervanhooft]

Scenarios:

• _link bears 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.
• _link bears testmode and messes up subsequent url (parameter) parsing

Impacted resource methods

• Customer
  • payments()
  • revokeMandate()
  • mandates()
  • getPresetOptions()
• Mandate
  • revoke()
• Payment
  • refund()
• Shipment
  • order()
• Subscription
  • cancel()

Impacted endpoint methods

• CustomerPaymentsEndpoint
  • createFor()
  • listFor()
• MandateEndpoint
  • createFor()
  • getFor()
  • listFor()
  • revokeFor()
• OrderLineEndpoint
  • cancelFor()
• OrderPaymentEndpoint
  • createFor()
• OrderRefundEndpoint
  • createFor()
• PaymentCaptureEndpoint
  • getFor()
• PaymentChargebackEndpoint
  • getFor()
• PaymentRefundEndpoint
  • getFor()
• ProfileMethodEndpoint
  • createFor()
  • createForCurrentProfile()
  • deleteFor()
  • deleteForCurrentProfile()
• ShipmentEndpoint
  • createFor()
  • getFor()
  • listFor()
• SubscriptionEndpoint
  • createFor()
  • getFor()
  • listFor()
  • cancelFor()
  • page()

Other

• Add mode attribute to all relevant Resources. Its availability is currently inconsistent.
• How does applying parameters to a url with 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.
• Should testmode be filtered from input parameters if already appended to the url?
• Would a oAuthTestmode() switch on to the client be a cleaner approach?
• MollieApiClient, check these methods:
  • rest_list
  • rest_create
  • rest_read
  • rest_delete
  • rest_update

[sandervanhooft]

Also see #417 .

@willemstuursma Significant impact. Any thoughts? I'll continue work on this this afternoon.

[sandervanhooft]

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

1. For root resources, use the urls generated by the client (no other choice here).
2. For subsequent calls to subresources, use the urls provided by the base resource. Ensure additional parameters can be provided.
3. For direct calls to subresources, keep on generating the url in the subresource endpoint. Parameters can be passed in manually.

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.

[sandervanhooft]

@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.

[sandervanhooft]

Closing this for now, let me know if it should be reopened.