feature/OVPAY-96 #8
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "feature/OVPAY-96"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
feature/OVPAY-96to WIP: feature/OVPAY-96@ -0,0 +45,4 @@schema:type: stringexample: Doe- name: emailAdressTypo: emailAddress (dubbel d, dubbel s)
@ -0,0 +97,4 @@schema:type: integerexample: 0123456789- name: OvChipcardAliasWaarom is deze nou ineens met een hoofdletter?
Omdat Mirjam dat getypt heeftlove you Mirjam@ -0,0 +158,4 @@"detail": "Meer dan 1 klantprofiel gevonden. Verfijn je zoekcriteria.","instance": "555d00b5-bc3f-4591-949b-479e76d49ea7"}/customers/tokens:Tobby schrijft voor dat dit endpoint
/customers/{customerId}/tokensmoet zijn. Doen we dat bewust niet omdat customerId in de JWT zit? Vindt Toby dat OK?@bboterm Dit is nu al zo gebouwd en is voor alle /customers endpoints in SE/Touchpoint nu zo - customerNumber/profileId wordt uit headers gehaald (uit JWT of uit SMP-gevulde header). Voordeel is dat je de customerNumber als touchpoint niet in de URI hoeft mee te geven. Sterker nog, als touchpoint weet je dat niet eens perse - in de klant JWT staat een Azure joejoe ID en in IL wordt die in database opgezocht om customerNumber te verkrijgen.
Dit aanpassen is dus niet triviaal, zeker omdat je dan als touchpoint, om je customerProfileId te verkrijgen, eerst een GET /customers/{customerProfileId} moet doen. Da wordt lastig
@ -0,0 +171,4 @@application/json:schema:$ref: '#/components/schemas/OvPayTokensResponse'/customers/tokens/{tokenId}/product-instances:API richtlijnen van Tobby schrijven voor dat je /customers weg kunt laten. Het tokenId is immers al uniek. Tevens is dit pad nu langer dan 3 delen, en dat mag niet.
Daarbij, sinds wanneer doen wij aan kebab case? We doen overal gewoon lowercase in urls.
@bboterm Ik heb /customers ervoor staan omdat:
Ik ben het in principe wel met je eens, dat het in het datamodel onder customers hangt, betekent niet dat het in API URI ook zo moet. /tokens is dan wel erg algemeen zonder context (dan kunnen het ook barrier tokens zijn), dan moeten we er /ovpaytokens van maken.
De URI aanpassen zal dan wel een breaking change zijn voor o.a. Perplex, TENZIJ ze de HATEOAS ook al gebruiken om de URI te bepalen en dan werkt het automagisch :o
@ -0,0 +243,4 @@type: stringformat: dateexample: '2023-02-01'emailAdress:Typo: emailAddress (dubbel d, dubbel s)
@ -0,0 +266,4 @@example: 1name:type: stringexample: BrugVoer hier liefst gewoon 'Home' in.
@ -0,0 +316,4 @@example: 1name:type: stringexample: MobielVul hier ook gewoon 'Home' in.
@ -0,0 +392,4 @@{ name: surname, required: false, type: string },{ name: suffix, required: false, type: string },{ name: dateOfBirth, required: false, type: string },{ name: emailAdress, required: false, type: string },Typo: emailAddress (dubbel d, dubbel s)
@ -0,0 +435,4 @@required:- ovPayTokensproperties:Entries:Waarom schrijf je hier 'Entries' en niet gewoon wat het zijn? 'ovPayTokens' ?
Had ik ook al gezien en gefixt, maar nog niet gepusht, snelle jongeman die je bent
WIP: feature/OVPAY-96to feature/OVPAY-96Pull request closed