Allright, I understood the API per se, I will leave the inheritance association within my UML Diagramme (as shown in the thread and descriebed in the Spec). As for the Patch-Operation it is clear that the path determine what the API-consumer wants to patch. By adding the mandatory fields in the AccountRef and the PaymentMethod_Update (Attribute: name) they also can be more specific. Hence no adding @- Tang Qinghua I've finished my design as we always change into swagger 3.0 and will continue with our developement. Cheers!
------------------------------
Erlina Hennies
Deutsche Telekom AG
------------------------------
Original Message:
Sent: Apr 11, 2023 04:11
From: Erlina Hennies
Subject: TMF670 - Payment Methods API - subclassing parameter(s) missing for patch?
Hi John,
I'm designing the services post and patch within PaymentMethod_API for Mobile and came across the issues Calin mentioned in the past.
So, when reading the spec, I understood that all the Enum-Variables are also objects of payment that are inheritance of the payment method.
to be able to update (partially) and create a payment method. (bank etc), it also means that a multiple inheritance of payment object types ( need to be build for PaymentMethod_Update and PaymentMethod_Create, correct? see screenshot
Secondly, when designing the patch, there is no parameter like @baseType, @schemaLocation, and/or at least @type within the object PaymentMethod_Update (for the request body). I assume this has been forgotten?
Regards,
Erlina
 <o:p></o:p>
------------------------------
Erlina Hennies
Deutsche Telekom AG
------------------------------
<o:p></o:p>
|
------------------------------
Erlina Hennies
Deutsche Telekom AG
------------------------------