Open SanderNotenbomer opened 3 years ago
### Meetings list
GET https://opendata.ibabs.eu/api/vergaderingen?vergaderingstypeId=1 HTTP/1.1
X-Api-Key: 10DAFA63-096D-4716-A2CA-29CEB3920C6D
ibabs-site-name: hoorn
### Single Meeting
GET https://opendata.ibabs.eu/api/vergaderingen/c5bb0b32-43b7-4f0c-95f8-0641b55f7f89 HTTP/1.1
X-Api-Key: 10DAFA63-096D-4716-A2CA-29CEB3920C6D
ibabs-site-name: hoorn
### Agenda Item
GET https://opendata.ibabs.eu/api/agendapunten/c530db74-88d4-467a-a4db-0f068764cb25 HTTP/1.1
X-Api-Key: 10DAFA63-096D-4716-A2CA-29CEB3920C6D
ibabs-site-name: hoorn
Lijkt goed te werken!
Ik heb een aantal API calls gechecked, het ziet er goed uit. Ik heb nog geen volledige scan van de API gedaan - dat is de volgende stap, in een prototype.
Wat ik mis, is een link naar een webpagina vanuit een vergadering of een agendapunt. Bijvoorbeeld: deze vergadering. DIe is voor een gebruiker te vinden op deze URL. In de API response staat de self link, die verwijst naar de API. Vanuit PLOOI (en naar ik zou verwachten ook vanuit andere gebruikers) is het nodig gebruikers door te verwijzen naar een dergelijke pagina. Hetzelfde geldt voor agendapunten. Het zou goed zijn als dit toegevoegd kan worden.
Verder zoek ik zoals besproken nog uit hoe we om zouden kunnen gaan met standaardisatie voor gemeentenamen (en/of identifiers), daar kom ik nog op terug.
Ik vraag me af waarom bij https://opendata.ibabs.eu/api/vergaderingen het vergaderingstypeId verplicht is. Ik neem aan dat dat voorlopig is en zodra de andere parameters beschikbaar zijn deze verplichting wegvalt. In de vergaderingen wil je op diverse parameters (bijvoorbeeld op datum) vrij kunnen zoeken.
Daarnaast is in de standaard het vergaderingstype gedefinieerd als enumeratie. Dit is juist vanuit standaardisatie-overweging zodat bij alle leveranciers dezelfde types worden gehanteerd las het gaat om het zoeken op het type vergadering.
Zodra dit in een een dynamische referentie-tabel wordt geplaatst (zoals dat nu gebeurt) worden de type-id's leverancier-specifiek. Dat betekent dat een hergebruiker voor iedere bevraging van raadsinformatie moet weten welke types de betreffende leverancier of de betreffende gemeente heeft gehanteerd.
De vergadering wordt nu in de collectie anders vormgegeven dan in opvraging op basis van de ID. Dat is verwarrend. Deze discussie hebben we tijdens het overleg kort gevoerd.
De verwijzing in de Json Hal draft is als volgt : 4.1.2. _embedded
The reserved "_embedded" property is OPTIONAL
It is an object whose property names are link relation types (as defined by [RFC5988]) and values are either a Resource Object or an array of Resource Objects.
Embedded Resources MAY be a full, partial, or inconsistent version of the representation served from the target URI.
De laatste zin was het argument om niet de volledige vergadering terug te geven in de collectie. In dit geval hebben we het niet over een embedded resource. Dit is de main resource. Eventuele direct meegeladen agendapunten bij een vergadering zouden embedded resources zijn.
Reden dus om de resources definitie van de collectie aan te passen.
De iBabs api is momenteel voor de eerste test versie opgeleverd. Deze is te vinden onder de url: https://opendata.ibabs.eu/api/ Er zijn 2 headers die expliciet gezet moeten worden anders werkt de api niet. Namelijk:
De 2e header value gaat verdwijnen zodra het model is aangepast om dit op te halen via een api call.
De volgende api calls zijn beschikbaar:
Je kunt je opmerkingen plaatsen bij dit issue zodat we kunnen bijhouden wat er gebeurd.