Closed rrutte closed 8 months ago
Ik vond die GET wel aardig, dus de vraag is eigenlijk: moeten beide partijen beide vormen ondersteunen? Of maken we 1 combinatie verplicht en 1 optioneel (indien beide partijen dat willen mag die ook)? Stel dat dit toegevoegd wordt dan praten we wel over 0.9.4 lijkt me. Of 0.9.3.1?
Wij hebben die niet als put op de radar staan. dus liever niet als verplicht.
Meenemen in de definitie voor de 0.9.3 voor SIS is GET response verplicht en PUT optioneel. Voor TPS is GET aanroepen verplicht en het PUT ontvangen optioneel.
@rrutte de PUT op groups is geen probleem. Voor een PUT op memberships moeten we denk ik nog wel even kijken wat het te verwachten gedrag is.
Standaard gedrag bij PUTs zoals we ze momenteel vanuit meerdere bronnen ontvangen is scenario 2. Omdat deze puts vaak eventgedreven obv het zetten van een begindatum/einddatm van de groepsdeelname worden gestuurd op het mutatiemoment is een hele array eigenlijk niet te doen.
Deelnames die worden aangepast/verwijderd komen dan ook bijna altijd individueel binnen.
Eens. We hebben in het membership een 'state' (active/canceled) dus daarmee kunnen we effectief een delete per persoon uitvoeren toch?
Laatste voorstel is: PUT /groups/{groupId}/members/{personId}
@hamrt In de beschrijving van flow 1 staat nog PUT /ooapi/group ipv groups
PUT /ooapi/group/{groupId}
{
"groupId": "123e4567-e89b-12d3-a456-426614174000",
"primaryCode": {
"codeType": "identifier",
"code": "1234qwe12"
},
"groupType": "learning group",
"name": [
{
"language": "en-GB",
"value": "statistics students"
}
],
"description": [
{
"language": "en-GB",
"value": "The group of students that follow statistics classes and related staff"
}
],
"startDate": "2020-08-17",
"endDate": "2020-12-18",
"personCount": 183,
"otherCodes": [
{
"codeType": "identifier",
"code": "1234qwe12"
}
],
"organization": "452c1a86-a0af-475b-b03f-724878b0f387"
}
update uitgevoerd
Vanuit koppeling met bv Osiris gaan we ervan uit dat de group en groupMemberships ook als PUT uit te voeren zijn. Dit in lijn met de andere flow 1 api's. Is hier bezwaar tegen en zo nee kan dit in de standaard geïmplementeerd worden?