De (mini-)ORI API is ontworpen om per API-call niet meer data dan nodig te bevragen. Resources (vergaderingen, agendapunten en informatieobjecten) zijn primair met behulp van URL's aan elkaar gerelateerd. Dit is conceptueel heel netjes, maar betekent wel dat het ophalen van een 'complete' vergadering (dus met bijbehorende agendapunten en informatieobjecten) relatief veel netwerkcalls met zich mee kan brengen.
Bijvoorbeeld:
vergadering ophalen op basis van {id}
agendapunt 1 ophalen via teruggekregen url
agendapunt 2 ophalen via teruggekregen url
agendapunt 3 ophalen via teruggekregen url
agendapunt n ophalen via teruggekregen url
informatieobjecten 1,2,3,[...] ophalen via teruggekregen {id's}
Een alternatief voor vergaderingen en agendapunten lijkt die altijd/alleen te bevragen met query parameter 'gewijzigdSinds'. Dan zouden altijd twee calls nodig zijn - voor iedere resource één. Informatieobjecten kunnen vervolgens op basis van id's in één extra call worden opgehaald.
De (mini-)ORI API is ontworpen om per API-call niet meer data dan nodig te bevragen. Resources (
vergaderingen,agendapunteneninformatieobjecten) zijn primair met behulp van URL's aan elkaar gerelateerd. Dit is conceptueel heel netjes, maar betekent wel dat het ophalen van een 'complete' vergadering (dus met bijbehorendeagendapunteneninformatieobjecten) relatief veel netwerkcalls met zich mee kan brengen.Bijvoorbeeld:
vergaderingophalen op basis van {id}Een alternatief voor
vergaderingenenagendapuntenlijkt die altijd/alleen te bevragen met query parameter 'gewijzigdSinds'. Dan zouden altijd twee calls nodig zijn - voor iedere resource één. Informatieobjecten kunnen vervolgens op basis van id's in één extra call worden opgehaald.Wat is hier gewenst?