Denne side beskriver adgangen til og den tekniske distribution af GraphQL, som er gældende for alle registre på Datafordeleren, der udstiller data med GraphQL.
Siden beskriver hvordan anvendere på Datafordeleren kan benytte GraphQL-tjenesterne til at hente tabulære data fra registrene.
På siderne om GraphQL bruges nedenstående begreber. Bemærk at begreberne også bliver yderligere forklaret med eksempler på siderne.
Begreb | Beskrivelse |
Nuværende Datafordeler | |
REST-tjenester: | REST-tjenester er en metode til at få data fra Datafordeleren. Du kan som anvender hente data ved at bruge en URL. REST-tjenester er beskrevet på REST på Datafordeleren. |
Moderniserede Datafordeler | |
GraphQL: | GraphQL beskrives i denne vejledning. |
Entitet: | En entitet er en fysisk repræsentation af et registerobjekt som findes i Grunddatamodellen. De total- og deltadownload, der kan hentes fra Datafordeleren, samt de entitetsbaserede GraphQL-tjenester indeholder hver især data bestående af en enkelt entitet. |
GraphQL-skemaer: | GraphQL-skemaer er .graphql-filer der genereres på baggrund af registrenes datamodeller og er yderligere beriget med metadata fra hvert register. Skemaerne beskriver hvordan data er struktureret og hvordan data kan hentes. |
Paging: | Paging er når resultater inddeles i sider således at resultater returneres én side ad gangen. |
GraphQL er et moderne API-sprog, der gør det muligt at hente data på en effektiv og fleksibel måde. GraphQL giver mulighed for at hente præcis de oplysninger, du som anvender skal bruge. GraphQL-tjenesterne er derfor velegnede når du ønsker at hente mindre datamængder og ikke nødvendigvis ønsker at postprocessere data efterfølgende.
Du kan bruge GraphQL-tjenesterne ved at sende en forespørgsel, der beskriver de data du ønsker, til Datafordeleren, hvorefter serveren kun svarer med de specifikke data, der blev anmodet om. Dette kan du blandt andet gøre gennem en desktop applikation eller gennem browseren ved brug af en browser-extension.
Med GraphQL kan du definere hvilke datafelter du ønsker returneret. Dette betyder, at du kun modtager de oplysninger, du har brug for. Det kan dermed forbedre svartiden for tjenesterne og reducere mængden af data, som overføres.
Yderligere information om GraphQL kan findes på graphql.org.
Måden du bruger GraphQL-tjenesterne på, er ved at sende en såkaldt query til et af Datafordelerens GraphQL-endepunkter. En query er anvendernes måde at definere hvilke data du ønsker at hente.
Et eksempel på en query mod tjenesten https://graphql.datafordeler.dk/BBR/v1 kan ses nedenfor.
GraphQL-queries fungerer således:
GraphQL-tjenester tilbydes som entitetsbaserede GraphQL-tjenester. Entiteterne baserer sig på datamodeller fra Grunddatamodellen. En entitet kan f.eks. være en "Adresse" fra DAR, en "Bygning" fra BBR eller et "Jordstykke" fra MAT.
Det at GraphQL-tjenesterne er entitetsbaserede betyder at et kald til en af tjenesterne returnerer data for en enkelt type af entitet. De entitetsbaserede GraphQL-tjenester leverer udelukkende tabulære data og ikke rasterdata (billeddata). Tabulære data forstås som strukturerede data der kan opbevares i tabeller, som f.eks. adresser, men ikke billeddata som f.eks. skærmkort.
Nedenstående figur giver et overblik over konceptet for entitetsbaserede GraphQL-tjenester. Figuren illustrerer 3 fiktive registre:
Figuren illustrerer at entitetsbaserede GraphQL-tjenester ikke udstiller relationer mellem entiteter, samt at tjenesterne ikke kan sammenstille entiteter. Den understøttede funktionalitet uddybes i de følgende afsnit.
GraphQL-tjenesterne udstilles gennem URL'er, der følger nedenstående form:
https://graphql.datafordeler.dk/<register>/<version>
<register> er forkortelsen for det register du som anvender forsøger at hente og <version> er versionen for det pågældende register. Versionering er yderligere beskrevet i afsnittet Versionering.
Alle registre, hvis entiteter udstilles via GraphQL-tjenesterne, er vist nedenfor.
Register | Forkortelse |
Bygnings- og Boligregistret | BBR |
Danmarks Administrative Geografiske Inddeling | DAGI |
Danmarks Adresseregister | DAR |
Danmarks Fikspunktregister | FIKSPUNKT |
DHM Højdekurver | DHMHoejdekurver |
DHM Oprindelse | DHMOprindelse |
Danske Stednavne | DS |
Det Centrale Virksomhedsregister | CVR |
Ejendomsbeliggenhedsregistret | EBR |
Ejendomsvurdering | VUR |
Ejerfortegnelsen | EJF |
GeoDanmark Vektor | GEODKV |
Historiske kort og data | HISTKORT |
Matriklen2 | MAT |
Skatteforvaltningens Virksomhedsregister | SVR |
Nogle registre indeholder data, f.eks. personoplysninger, som kræver godkendelse for at kunne tilgås. Disse data kaldes på Datafordeleren for adgangsbegrænsede data.
Adgang til adgangsbegrænsede data tildeles af registrene ved at en anvender opretter et IT-system og laver en ansøgning gennem selvbetjeningen til det specifikke register på vegne af det nyoprettede IT-system, hvorefter det pågældende register først skal godkende ansøgningen før data kan tilgås. Læs mere om Brugeradgang på datafordeler.dk og hvordan et IT-system oprettes på IT-systemer.
Tabellen nedenfor viser hvilke registre der indeholder adgangsbegrænsede data:
Register | Entiteter |
CVR | CVRPerson |
EJF | Alle entiteter |
SVR | Alle entiteter |
Bemærk Der er kun adgang til de fortrolige entiteter fra EJF for offentlige myndigheder. |
Entiteten CVRPerson fra CVR har et enkelt felt som indeholder adgangsbegrænsede data, mens resten af felterne ikke er adgangsbegrænsede. Datafordeleren udstiller derfor den specialudviklede entitet CVRPersonBegraenset gennem en GraphQL-tjeneste, der giver anvendere mulighed for at hente en ikke-adgangsbegrænset udgave af entiteten CVRPerson. Entiteten CVRPersonBegraenset er identisk med CVRPerson bortset fra at feltet CPRPerson er fjernet.
Filtreringsmulighederne på CVRPersonBegraenset-entiteten er de samme som tillades på CVRPerson-entiteten, bortset fra at det ikke er muligt at filtrere på CPRPerson-feltet. GraphQL-skemaet ligner det for CVRPerson-entiteten, dog uden CVRPerson-feltet.
Tjenesten er tilgængelig på følgende URL:
https://graphql.datafordeler.dk/CVR/custom/<version>
GraphQL-tjenesterne understøtter almindelige sammenligningsoperatorer og filtreringsmuligheder (f.eks. <, >, =, in). Nedenstående tabel viser eksempler på datatyper og understøttede operatorer. Det skal bemærkes, at det fremgår i GraphQL-skemaerne for de enkelte registre, hvilke filtreringsmuligheder der er for hver entitet og dennes felter. Tabellen kan ikke anvendes som reference når der skal sammensættes queries til det enkelte register, da det afhænger af den specifikke entitet og dennes felter præcis hvilke operatorer der er understøttet. Læs mere om GraphQL-skemaer.
Det er muligt at bruge flere filtre i den samme query, selvom der er nogle begrænsninger for, hvordan filtrering er tilladt.
Datatyper | Understøttede operatorer |
Comparable (Float, Int, Long, Short) |
|
Comparable (Date, DateTime, TimeSpan) |
|
Text (String) |
|
Boolean |
|
Bemærk Det fremgår i GraphQL-skemaet for det enkelte register, hvilke filtreringsmuligheder der kan anvendes for de enkelte entiteter og deres felter. Tabellen kan ikke anvendes som reference når der skal sammensættes queries til det enkelte register, da det afhænger af den specifikke entitet og dennes felter præcis hvilke operatorer der er understøttet. |
GraphQL-tjenesterne understøtter også geospatiale data og du kan derfor benytte filtre i form af WKT-strenge (Well Known Text) som gives som input til de geometriske filtre. Disse WKT'er repræsenterer geospatiale data, enten i form af en koordinattype, en geometri-type eller lignende datatyper.
De mest almindelige typer af geometriske former er punkter, linjer og polygoner. Et punkt repræsenteres af et koordinatsæt med to eller tre værdier, afhængigt af om det er et punkt i to eller tre dimensioner. En linje repræsenteres af koordinatparrene eller koordinattripletterne for de punkter, der udgør linjen, og en polygon repræsenteres af koordinatpar eller koordinattripletter, der udgør hjørnerne af polygonen. Et eksempel på WKT-formatet for hver af de tre geometrityper i 2D, er vist i nedenstående figur.
Point POINT (3 5) Line LINESTRING (6 4, 8 2, 7 1) Polygon POLYGON (1 1, 3 3, 4 2, 4 0, 1 1) |
Datafordeleren understøtter en række forskellige operatorer. Alle operatorerne fremgår sammen med et link til deres PostGIS-dokumentation i tabellen nedenfor, og hver af funktionerne tager to geometriske former og returnerer en Boolean værdi. Kombinationer af forskellige filtre understøttes også ved hjælp af AND/OR-operatorer.
Datatyper | Understøttede operatorer | PostGis Link |
Geometri | contains(koordinatsystem, geometri) | |
covers(koordinatsystem, geometri) | ||
coveredBy(koordinatsystem, geometri) | ||
crosses(koordinatsystem, geometri) | ||
intersects(koordinatsystem, geometri) | ||
within(koordinatsystem, geometri) | ||
overlaps(koordinatsystem, geometri) | ||
touches(koordinatsystem, geometri) |
Et eksempel på hvordan operatoren contains bruges kan ses i nedenstående figur.
De geometriske filtre er implementeret således, at hvis man læser informationen i PostGIS-dokumentation link i tabellen ovenfor, er geometri A altid værdien af registerdatafeltet, og geometri B altid inputgeometrien. Det vil sige, at rækkefølgen er operator(<registerdatafelt>, <input>). Hvis du ønsker den modsatte rækkefølge, bør du i stedet bruge en anden geometrisk operator, der repræsenterer den omvendte operator. En oversigt over disse kan ses i nedenstående tabel.
Geometrisk operator | Omvendte operator |
contains | within |
covers | coveredBy |
coveredBy | covers |
crosses | Ingen. crosses er symmetrisk |
intersects | Ingen. intersects er symmetrisk |
within | contains |
overlaps | Ingen. overlaps er symmetrisk |
touches | Ingen. touches er symmetrisk |
Syntaksen for at bruge geometriske filtre, og hvilke felter der kan filtreres geometrisk, er specificeret af GraphQL-skemaet for den pågældende tjeneste, som du ønsker at bruge.
Da geospatiale data kan have forskellige formater afhængigt af, hvilket register det drejer sig om, udfører Datafordeleren udelukkende validering på om det angivne koordinatsystem (CRS) er det samme koordinatsystem som registrets data og at den angivne WKT er valid og repræsenterer en topologisk valid geometri som specificeret i OGC SFS-specifikationen.
På entiteter med bitemporale felter (forklares nærmere på Bitemporalitet på datafordeler.dk) er følgende to typer queries ofte anvendt:
Ved interval-queries har du mulighed for at specificere standardfiltre, på de bitemporale felter. Ved point-in-time-queries understøttes valgfrie argumenter for registreringstid og virkningstid, som kan angives, når du sender queries. Når disse argumenter ikke gives, returneres fuldt bitemporale data.
GraphQL-tjenesterne understøtter muligheden for at kombinere point-in-time-filtrering med enhver anden filtrering, der er tilladt, så du kan hente data, der overholder det angivne tidspunkt samt eventuelle intervalfiltre, geo-filtre eller lignende, du har angivet. Det vil sige, når point-in-time-filteret kombineres med andre filtre, vil forespørgslen ende med at være "point-in-time-filter OG (andre filtre)". Det er ikke muligt at sige point-in-time-filtreret 'ELLER' noget andet filter.
Bemærk For at få data som er gyldigt på et givent tidspunkt, skal du sætte både virkningstid og registreringstid til forespørgselstidspunktet for at få data, der er gyldige på det pågældende tidspunkt. |
Alle registre der understøtter bitemporal filtrering, understøtter filtrering på både virkningstidspunkt og registreringstidspunkt bortset fra CVR. CVR er det eneste register, hvor du ikke kan specificere et registreringspunkt i din query. For CVR sættes registreringstidspunktet derimod altid til tidspunktet for forespørgslen, dvs. “registreringstid = NOW()”. Det er muligt at filtrere på virkningstidspunktet på sædvanlig vis.
På entiteter med bitemporale felter kræves minimum ét af følgende filtre:
Filtreringstype | Filter |
Bitemporal filtrering | Point-in-time filter på registreringstid |
Bitemporal filtrering | Point-in-time filter på virkningstid |
Standardfiltrering | Operator på feltet id_lokalid |
GraphQL-tjenesterne kræver paging af resultater. At resultaterne pagineres vil sige at resultaterne inddeles i ”sider” og returneres én ad gangen. Du vil således få én side returneret ad gangen og kan efterfølgende lave et nyt kald for at få næste side for på den måde at gennemgå hele datasættet.
Paging er cursor-baseret, hvilket vil sige at der returneres en reference, en såkaldt cursor, til første og sidste resultat (for edges ved hvert enkelt resultat) i det returnerede datasæt ved hvert kald. Denne cursor kan derefter bruges til at hente flere sider ved at anmode om mere data fra cursorens værdi. I praksis kan du bruge cursor-værdien i en efterfølgende query, til at hente den næste side af data, startende fra den position, der er angivet ved den pågældende cursor. Paging er implementeret således at flere identiske anmodninger ved hjælp af den samme cursor vil returnere de samme data, forudsat at registrene ikke opdaterer de underliggende data i mellemtiden.
Paging er udelukkende implementeret som fremadgående paging. Det vil sige, at du kan hente den næste side af resultater fra en given cursor. Bagudgående paging understøttes ikke.
Paging består af tre datastrukturer: PageInfo samt nodes eller edges.
PageInfo indeholder metadata om den nuværende paging og består af følgende felter:
Mens metadata kan hentes via PageInfo, kan data hentes enten som en liste af nodes eller en liste af edges. Nodes og edges adskiller sig på følgende måde:
Det anbefales, at du benytter nodes til simpel paging, da PageInfo-metadataene er tilstrækkelige. Hvis du har brug for at paging fra en hvilken som helst position på den aktuelle side og ikke fra slutningen af den aktuelle side, skal edges benyttes.
Det er tilladt for anvendere at specificere i GraphQL-queries, at de ønsker både nodes og edges returneret. Dette frarådes, da resultatsættet vil indeholde de samme data to gange.
Paging har to inputargumenter, der kan specificeres i en query:
Hvis du angiver ugyldige værdier for nogen af disse argumenter, vil tjenesterne returnere en fejlmeddelelse, der informerer om, at der er angivet ugyldige paging-argumenter.
Følgende query kan bruges til at hente de første 5 datapunkter (første side) af BBR_Bygning-entiteten:
Tjenesten returnerer følgende resultat:
Fra hasNextPage i resultatet ovenfor kan man se at der er flere sider, da den er sat til true. For at hente den næste side kan du derfor bruge endCursor som after-værdi i den efterfølgende query:
Ved iterativt at gentage dette mønster kan alt den ønskede data hentes.
For alle de registre der er udstillet gennem Datafordelerens GraphQL-tjenester, kan du hente GraphQL-skemaer, der beskriver hvordan data er struktureret. Skemaerne specificerer de typer data, der kan hentes, relationerne mellem disse typer og de filtreringsoperationer, der kan understøttes for de pågældende felter. Du kan benytte skemaerne til at se hvilke queries du kan sende, og hvilke data du kan hente.
Skemaerne genereres på baggrund af registrenes datamodeller og er beriget med metadata for hvert register. Denne metadataudtrækningsproces involverer at tage relevant information fra datamodellerne og inkorporere den i skemaerne. Denne ekstra metadata giver anvendere mere omfattende indsigt i de tilgængelige data. Skemaerne findes separat for hvert register og kan hentes ved at tilgå nedenstående url:
https://graphql.datafordeler.dk/<register>/<version>/schema
<register> er forkortelsen for det register anvenderen forsøger at hente og <version> er versionen for det pågældende register. Skemaet for version 1 af Skatteforvaltningens Virksomhedsregister (SVR) hentes for eksempel på følgende url:
https://graphql.datafordeler.dk/SVR/v1/schema
I GraphQL-tjenesterne versioneres hvert register separat, og alle entiteter, der tilhører det samme register, versioneres under det samme versionsnummer som registret. Det vil sige, at DAR og BBR kan eksistere separat som DAR/v2 og BBR/v5. Men hvis BBR har en change til Bygning-entiteten i deres datamodel, vil alle entiteter i BBR blive opgraderet til BBR/v6, og BBR/v5 vil derefter efter en overgangsperiode blive udfaset.
Som en sikkerhedsforanstaltning og af performance-hensyn tilskrives hver query en cost. En cost er en beregnet talværdi der indfanger hvor kompleks og omkostningstung en given query er for Datafordeleren at processere. Cost udregnes inden en query processeres.
Udregningen af cost er blandt andet baseret på følgende specifikationer:
Bemærk Der håndhæves aktuelt ikke en grænse på cost før en query processeres af Datafordeleren. Det er dog en mulighed der kan finde anvendelse hvis der skulle opstå et behov. Såfremt dette behov skulle opstå, vil det blive kommunikeret inden der etableres en max cost på GraphQL tjenesterne. |
GraphQL-tjenesterne på Datafordeleren tilgås via et GraphQL-API. Dette afsnit beskriver, hvordan det vil være muligt at danne et overblik over hvilke entiteter du kan tilgå, samt hvordan data hentes.
GraphQL-tjenesterne kan tilgås på registerbasis og kræver at du benytter en af de tre autentifikationsmetoder.
Ovenstående figur viser hvordan GraphQL-API'et overordnet set anvendes. Her hentes GraphQL-skemaet først for det pågældende register ved at tilgå https://graphql.datafordeler.dk/<register>/<version>/schema, hvorefter det ønskede data hentes, ved at sende en query til https://graphql.datafordeler.dk/<register>/<version>.
Hent Schema | |
URL | https://graphql.datafordeler.dk/<register>/<version>/schema |
HTTP-metode | GET |
Headere i forespørgsel | Content-Type: application/json |
Returværdier | · Returnerer HTTP 200 – OK, ved succes. · Returnerer HTTP 400 – Bad Request, ved angivelse af forkerte parametre. · Returnerer HTTP 404 – Not Found, hvis den angivne ressource ikke kan findes. · Returnerer HTTP 500 – Internal Server Error, hvis der er sket en ukendt fejl |
Adgang | IT-system med API-nøgle, OAuth Shared Secret eller OAuth Certifikat. |
Navn | Type | Beskrivelse | Obligatorisk |
Register | String | Angiver hvilket register det pågældende skema skal hentes for.
| Ja |
Version | String | Angiver hvilken version af datamodellen det pågældende register skal være. | Ja |
Denne tjeneste returnerer altid en fil ved HTTP 200 – OK. Filen indeholder et GraphQL-schema med metadata om GraphQL-tjenesten, der beskriver hvilke entiteter der findes for det pågældende register og hvordan data fra disse hentes.
Hent skema for DAGI med versionsnummer v1 ved brug API-nøgle:
Send query | |
URL | https://graphql.datafordeler.dk/<register>/<version> |
HTTP-metode | GET & POST |
Headere i forespørgsel | For POST-requests: · Content-Type: application/json For GET- og POST-requests (valgfrit): · Accept: application/graphql-response+json |
Body | For GET-requests: · Ingen. Query-parametre skal URL-encodes i overensstemmelse med GraphQL-standarden. For POST-requests: · Valid GraphQL-query. |
Returværdier | · Returnerer HTTP 200 – OK, ved succes. · Returnerer HTTP 400 – Bad Request, ved angivelse af forkerte parametre. · Returnerer HTTP 404 – Not Found, hvis den angivne ressource ikke kan findes. · Returnerer HTTP 500 – Internal Server Error, hvis der er sket en ukendt fejl |
Adgang | · Ikke-adgangsbegrænset data: IT-system med API-nøgle, OAuth Shared Secret eller OAuth Certifikat. · Adgangsbegrænset data: IT-system med OAuth Shared Secret eller OAuth Certifikat og på en defineret IP-Allowlist og så skal IT-systemet have eksplicit godkendelse fra det pågældende register. Se afsnit 3 for yderligere information. |
Bemærk Du bør som anvender inkludere Accept-headeren som specificeret her, hvis du vil opt-in til moderne GraphQL-over-HTTP. Dette er dog ikke et krav. Hvis Accept-headeren ikke inkluderes fås andre HTTP-statuskoder. |
Bemærk Returværdierne for HTTP-statuskoderne afhænger af hvilken Accept-header der specificeres. Værdierne i tabellen er hvis Accept-headeren ikke er angivet som beskrevet i ”Headere i forespørgsel”. |
Navn | Type | Beskrivelse | Obligatorisk |
Register | String | Angiver hvilket register det pågældende skema skal hentes for.
| Ja |
Version | String | Angiver hvilken version af datamodellen det pågældende register skal være. | Ja |
Denne tjeneste returnerer et json-response ved HTTP 200 – OK.
Hent de første 100 datapunkter fra entiteten DAR_Adresse fra version 1 af DAR inden for den angivet periode ved at sende nedenstående query ved brug af API-nøgle:
Hent data der var gældende den 12/11/2024, kl. 14:41:33 med kommunekode “0550” fra entiteten BBR_Bygning fra version 1 af BBR ved at sende nedenstående query som et POST-request ved brug af API-nøgle:
Når du ønsker at benytte GraphQL-tjenester kræver det at anvenderen er autentificeret. Datafordeleren har en række forskellige autentifikationsmetoder, som skal benyttes afhængigt af om du forsøger at tilgå frit tilgængeligt eller adgangsbegrænset data:
Bemærk Det er ikke muligt at benytte tjenestebruger til autentifikation for at hente data via GraphQL-tjenesterne. |
I OAuth er et Access Token en hemmelig nøgle som er med til at identificere en anvender hos Datafordeleren, uden at kende til brugernavn eller et password. Når du laver en query med et Access Token i en Authorization header med et Bearer Token, kan Datafordeleren finde ud af hvilke rettigheder og roller som du har. En query bliver derfor afvist hvis dit Access Token mangler.
Nedenstående tabel indeholder en beskrivelse af de oplysninger der skal angives for at få udstedt et Access Token.
Client credentials | Beskrivelse | Eksempel på værdi |
Client_id | Her skal angives den værdi som fremgår i ”Client ID”-kolonnen i overblikket over OAuth Shared Secret. | 00001111-aaaa-2222-bbbb-3333cccc4444 |
Client_secret | Her skal angives værdien som blev vist da Shared Secret blev oprettet i Datafordeler Administration. | qWgdYAmab0YSkuL1qKv5bPX |
Grant_type | Skal altid sættes til “client_credentials”. | client_credentials |
Når du har modtaget et Access Token, skal det angives i en Authorization header i kaldet til tjenesterne. Nedenstående tabel beskriver hvorledes Access Token angives i kaldet.
HTTP header | Beskrivelse | Eksempel på værdi |
Authorization | Her skal angives det Access Token som blev sendt tilbage ved kald til https://auth.datafordeler.dk/realms/distribution/protocol/openid-connect/token. Bemærk at eksemplet er forkortet og at det faktiske Access Token er betydeligt længere. | Bearer eyJhbGciOiJSUzI1NiIsI…. |
Hvis du som anvender ønsker at bruge Shared Secret og Client Id til at sende en query til Datafordelerens GraphQL tjeneste kan du med fordel bruge et program som f.eks. Postman, som understøtter både GraphQL-queries og OAuth-opsætning.
Når OAuth credentials er oprettet i Datafordeler Administration, kan du gå i gang med OAuth-opsætningen i Postman. Her er det vigtigt at du noterer dit Client ID og Shared Secret da disse værdier skal bruges til at hente et Access Token igennem Datafordeleren som blandt andet giver adgang til GraphQL-tjenesten.
1) Åben Postman og klik på ”Collections” i venstre side. Collections er en folder/mappe med et bestemt navn, hvor du kan samle alle dine queries til Datafordeleren og eventuelt navngive dem efter behov.
For at oprette en collection trykker du på ”+” ikonet og vælger ”Blank collection”. Derefter kan du i toppen navngive din collection.
2) Når en collection er oprettet, kan du oprette en request ved at højreklikke på sin collection eller trykke på de 3 prikker og derefter vælge ”Add request”.
Her kan du også navngive din request efter behov.
3) Når requesten er oprettet kan du i HTTP metoden vælge GET, hvis du vil hente et GraphQL-skema, eller POST hvis du vil sende en query.
Dette eksempel tager udgangspunkt i en POST request med OAuth-credentials til BBR.
I feltet til URL’en kan du indsætte https://graphql.datafordeler.dk/BBR/v1 for at kunne lave queries til BBR-version 1.
4) Vælg requesten i venstre side (hvis den ikke allerede er aktiv som i det forrige trin) og klik på ”Authorization” for at skifte til en anden fane. Her skal du vælge ”OAuth 2.0” i ”Auth Type” menuen.
Postman skulle gerne skifte indholdet når du har valgt en ny auth type.
5) Du skal herefter scrolle ned i den aktive ”Authorization” fane indtil du kan se en ”Configure New Token” overskriften.
Under overskriften vil der være en række felter som skal udfyldes som beskrevet herunder.
6) Efter du har udfyldt de nødvendige felter, kan du hente dit Access Token ved at rulle ned indtil du ser en orange knap der hedder ”Get New Access Token” og klikke på den.
Derefter vil Postman åbne et vindue som indikerer at applikationen er gået i gang med at hente Access Token fra Datafordeleren.
Når Access Token er hentet, vil Postman opdatere vinduet med et grønt flueben og med teksten ”Authentication complete”. Herefter kan du vente 5 sekunder eller trykke på ”Proceed” knappen i nederste højre hjørne. Herefter vil Postman åbne et nyt vindue.
7) Når Postman har åbnet det næste vindue, vil Access token og dets navn stå under ”Token Details”.
Du kan nu trykke på ”Use Token” til at bruge den til at lave queries i Postman eller kopierer access token til anden applikation.
8) Hvis du trykker på ”Use Token” vil Postman automatisk udfylde det i den request som du oprettede tidligere. Herefter kan du lukke vinduet og klikke på ”Body” fanen, efterfuldt ved at klikke på GraphQL muligheden længst til højre. Til sidst kan du skrive en GraphQL-query til BBR og indsætte det i ”Query” tekstfeltet.
9) Når du er klar til at indsende din query kan du trykke på ”Send” oppe i højre hjørne.
Herefter vil svaret fra GraphQL tjenesten blive vist i bunden.
10) Du er nu klar til at indsende queries til Datafordeleren som bruger OAuth 2.0 Client Id og Client Secret til at autentificere til GraphQL tjenesterne.
Såfremt du skal sætte Postman op med OAuth certifikat, skal du sætte OAuth 2.0-indstillinger op, samt vedhæfte et certifikat i Postman.
Fremgangsmåden er næsten den samme som beskrevet under eksemplet med Shared Secret, dog med få forskelle. Fremgangsmåden er som følger:
1) Punkt 1-4 følges, som de er beskrevet ovenfor under eksemplet med Shared Secret.
2) Herefter skal OAuth 2.0-indstillinger opsættes for certifikatet. Gå ind under ”Authorization” i requesten, og scroll ned til ”Configure New Token”.
Under overskriften vil der være en række felter som skal udfyldes som beskrevet herunder.
a. I ”Token Name” kan du give din Access Token et passende navn.
b. I ”Grant type” menuen skal du vælge ”Client Credentials”. Her vil Postman ændre felterne under med dem som relevant for din konfiguration af OAuth.
c. I ”Access Token URL” skal du indsætte følgende link - https://auth-oces.datafordeler.dk/realms/distribution/protocol/openid-connect/token.
d. I ”Client ID” skal anvenderen indsætte det Client ID som de har modtaget efter at have oprettet det i OAuth sektionen på Datafordeler Administration.
e. Du kan ignorere ”Scope” feltet, men skal verificere at ”Client Authentication” feltet er sat til ”Send client credentials in body”.
3) Vælge ”Settings” oppe i højre hjørne:
4) Vælg herefter ”Add Certificate”.
5) Angiv herefter ”host” og certifikatet.
6) Punkt 6-10 følges, som de er beskrevet ovenfor under eksemplet med Shared Secret.