De Verzoek Type Catalogus biedt een overzicht van mogelijke door de gebruiker te starten verzoeken en de te verwachten afhandeling. Het component laat zich in deze het best vergelijken met een digitale beschrijving van een formulier, waarbij de Verzoek Type Catalogus zich zuiver beperkt tot de definiëring van de eindwaarde. Het bevat in deze dus een reeks van velden en voorwaarden waaraan het moet voldoen.
De door de gebruiker aan te leveren velden noemen we properties, en iedere property kan worden beschreven. Voor het omschrijven van de velden gebruiken we de OpenAPI Standaard als richtlijn, dat betekent dat alle daarin opgenomen typering voor velden mogen worden toegepast. Dit kan op een aantal manieren:
Simpel: bijvoorbeeld een naam is een string van minimaal 5 en maximaal 255 teken. Abstract: bijvoorbeeld een link is een geldige URL
Linked Data: en vanuit de Common Ground gedachte kan het ook in de trant van een linked data object beschrijving. In dat laatste geval wordt gebruik gemaakt van de OpenAPI 2 norm extensie voor types. Waarbij een type wordt gedefinieerd als componentCode/resource. Bijvoorbeeld een persoon is een cc/people (ofwel een persoon in het Contacten Component).
Linked data bevindt zich per definitie in andere componenten die bronhouder zijn, dat wil zeggen dat in de dataset van een verzoek alleen de verwijzing naar de bron wordt opgeslagen. Er kan echter wel gebruik worden gemaakt van de in NL API strategie omschreven extend functionaliteit. Dat wil zeggen dat het mogelijk is om aan de VTC API te vragen om externe bronnen in te voegen als objecten in plaats van verwijzingen. Op deze manier is het mogelijk om een verzoek met onderliggende data in één keer op te halen.
Omgekeerd is het ook mogelijk om onderliggende resources in andere componenten aan te maken (door in plaats van een verwijzing een object mee te geven, maar niet te voorzien van een id property) of deze bij te werken (door in plaats van een verwijzing een object mee te geven, maar wel te voorzien van een id property).
Als laatste kan een verzoek type ook spelregels bevatten over wat er moet gebeuren als een verzoek van status verandert. Zo is het bijvoorbeeld mogelijk om bij het indienen van een verzoek, een zaak van een bepaald zaaktype te laten aanmaken in een API die de ZGW standaard ondersteunt of om bij bijvoorbeeld het opstarten van een verzoek een Camunda proces op te starten.
We differentiate between two way's of installing this component, a local installation as part of the provided developers toolkit or an helm installation on an development or production environment.
First make sure you have docker desktop running on your computer. Then clone the repository to a directory on your local machine through a git command or git kraken (ui for git). If successful you can now navigate to the directory of your cloned repository in a command prompt and execute docker-compose up.
$ docker-compose up
This will build the docker image and run the used containers and when seeing the log from the php container: "NOTICE: ready to handle connections", u are ready to view the documentation at localhost on your preferred browser.
As a haven compliant commonground component this component is installable on kubernetes trough helm. The helm files can be found in the api/helm folder. For installing this component trough helm simply open your (still) favorite command line interface and run
$ helm install [name] ./api/helm --kubeconfig kubeconfig.yaml --namespace [name] --set settings.env=prod,settings.debug=0,settings.cache=1
For an in depth installation guide you can refer to the installation guide contained with the helm files, it also contains a short tutorial on getting your cluster ready to expose your installation to the world
This component adheres to international, national and local standards (in that order), notable standards are:
- Any applicable W3C standard, including but not limited to rest, JSON-LD and WEBSUB
- Any applicable schema standard
- OpenAPI Specification
- GAIA-X
- Publiccode, see the publiccode for further information
- Forum Stanaardisatie
- NL API Strategie
- Common Ground Realisatieprincipes
- Haven
- NLX
- Standard for Public Code, see the compliancy scan for further information.
This component is based on the following schema.org sources:
You can find the data model, OAS documentation and other helpfull developers material like a postman collection under api/public/schema, development support is provided trough the samenorganiseren slack channel.
Couple of quick tips when you start developing
- If you not yet have setup the component locally read the Tutorial for setting up your local environment.
- You can find the other components on Github.
- Take a look at the commonground componenten catalogus to prevent development collitions.
- Use Commongroun.conduction.nl for easy deployment of test environments to deploy your development to.
- For information on how to work with the component you can refer to the tutorial here.
First of al please read the Contributing guideline's ;)
But most imporantly, welcome! We strife to keep an active community at commonground.nl, please drop by and tell is what you are thinking about so that we can help you along.
Information about the authors of this component can be found here
Copyright © Utrecht 2019