BBR REST efter 15. januar 2027: samme sti, ny vært

datafordelerOpdateringstid er GraphQL-kildens egen indlæsningstid

Feltet angiver hvornår rækken blev indlæst i Datafordelerens GraphQL-lager, ikke i REST-tjenestens. Værdien er derfor en anden end REST svarede: typisk 0,1–2 sekunder senere, men op til et par døgn for rækker der blev konverteret i april 2021. Det gælder også i indlejrede objekter (etage, opgang, ejendomsrelation, sagsniveau). Alle andre felter havde identiske værdier i paritetsprøverne.

Gør sådan: Brug ikke feltet til at sammenligne med gemte REST-svar. Ved ændringsudtræk via DAFTimestampFra/Til: start et nyt vandmærke fra dette endpoints værdier.

Kilde: Paritetsfixtures (767 REST-objekter, 32 959 sammenlignede værdier): alle 1 579 afvigende værdier var dette felt.

DAFTimestampFra/Til filtrerer på GraphQL-kildens opdateringstid

DAFTimestampFra/Til understøttes og filtrerer på datafordelerOpdateringstid — men det er GraphQL-lagerets tidsstempel (se ovenfor), så grænserne falder ikke præcis som i REST.

Gør sådan: Læg en sikkerhedsmargin på nogle minutter ind i inkrementelle udtræk.

Kilde: Følger af afvigelsen på datafordelerOpdateringstid.

Indlejrede lister er sorteret efter id_lokalId

etageList, opgangList, ejerlejlighedList, bygningPåFremmedGrundList og sagsniveauList indeholder de samme elementer som REST, men sorteret efter id. REST brugte en ikke-dokumenteret rækkefølge.

Kilde: Paritetsfixtures (listerne sammenlignes som mængder).

fordelingsarealList udelades

bygningenhed

REST-skemaet beskriver en fordelingsarealList på bygning og enhed. Den forekom ikke i nogen af de indsamlede REST-svar og leveres ikke her. Filteret Fordelingsareal understøttes.

Kilde: BBR_2.4.4_Bygning/Enhed.schema.json; 0 forekomster i 6 000+ indsamlede REST-objekter.

UTC-offset på tidspunkter før 1970 kan afvige

Tidspunkter skrives i dansk tid med offset som i REST (fx +02:00). Offset beregnes med tz-databasen, som siden 2022 deler historik for Danmark med Tyskland; for sommertid i 1916 og 1940–1948 kan offset derfor afvige fra REST. Før 1894 skrives +00:50 som REST gjorde.

Kilde: serialize.ts; REST-værdien 1753-01-01T00:50:00.000000+00:50 fra paritetsprøverne.

VirkningFra/Til og RegistreringFra/Til kun som ét tidspunkt

REST tog et interval pr. tidsakse og returnerede alle versioner, der overlappede det. GraphQL-kilden svarer for ét tidspunkt pr. akse. Fra og Til understøttes derfor kun når begge er angivet med samme værdi (fx VirkningFra=2020-01-01T00:00:00&VirkningTil=2020-01-01T00:00:00). Et interval afvises med 400. Uden parametrene svares for nu, som REST. Tidspunkter uden tidszone tolkes som dansk tid.

Gør sådan: Hent en historik som en række enkelt-tidspunkter, eller brug Grundfasts /v1/bbr/.../historik.

Kilde: Paritetsfixture bygning-instant-2020 (et tidspunkt i 2020 gav samme version som REST).

PeriodeaendringFra/Til og KunNyesteIPeriode=true afvises

Filtrering på periodeændringer findes ikke i GraphQL (KDS’ oversættelsesvejledning: "ikke muligt i GraphQL"). Parametrene afvises med 400. KunNyesteIPeriode=false accepteres, da det er standardværdien.

Kilde: KDS: Brugervejledning – udvalgte REST-tjenester omsat til GraphQL-queries, afsnit BBR.

Enkelte metadata-filtre findes ikke i GraphQL-kilden

tekniskanlaegejendomsrelation

GraphQL kan ikke filtrere teknisk anlæg og ejendomsrelation på Forretningsomraade, Forretningshaendelse, Virkningsaktoer eller Registreringsaktoer. Parametrene afvises med 400 på de to metoder (de virker på de øvrige).

Kilde: BBR_TekniskAnlaegFilterInput / BBR_EjendomsrelationFilterInput i det publicerede BBR.graphql.

Nord/Syd/Oest/Vest kræver alle fire

bygningtekniskanlaeg

Et afgrænsningsfelt (EPSG:25832, som i REST) understøttes, men kun med alle fire kanter. REST accepterede også en delvis afgrænsning; her afvises den med 400.

Kilde: Paritetsfixture bygning-bbox (samme 100 bygninger som REST).

Ved sideskift kan et id med "aa" havne på naboside

REST sorterede id_lokalId som ren tekst. GraphQL-kilden sorterer med dansk kollation, hvor "aa" tæller som "å" og kommer efter "z". Inden for en side sorteres svaret som REST, men hvilken side et id med "aa" lander på kan afvige: i stikprøver flyttede 0–35 af 1 000 objekter pr. side. En fuld gennemløbning side for side returnerer præcis de samme objekter, hvert én gang.

Gør sådan: Gennemløb hele listen og dedupliker ikke på sidenummer. Forvent ikke at side N indeholder præcis de samme id’er som side N hos REST.

Kilde: Live-prøver 2026-10-27: bygning/enhed/teknisk anlæg/ejendomsrelation i kommune 0101, 0751, 0760.

Indirekte filtre returnerer id-sorteret

Ved filtre der slås op via et andet objekt (fx BBRSag?Bygning=, bygning?BFENummer=) returnerede REST i sin egen join-rækkefølge. Her er svaret altid sorteret efter id_lokalId. Indholdet er det samme.

Kilde: Paritetsfixture bbrsag-bygning.

PageSize højst 1 000

REST accepterede sider på 10 000 og mere. Her er grænsen 1 000 pr. side; standard er 100 som i REST. page/pagesize starter ved 1 og kan ikke kombineres med count, som i REST.

Kilde: limits.ts (BBR_REST_MAX_PAGE_SIZE).

Spring direkte til en dyb side er begrænset

GraphQL-kilden har ingen offset, kun en cursor. Sider der hentes i rækkefølge (1, 2, 3 …) koster ét opslag hver, uanset hvor dybt. Et koldt spring direkte til en side mere end 10 000 objekter forbi den senest leverede side afvises med 400.

Gør sådan: Bladr sekventielt, eller indsnævr filteret (fx med Status eller Kommunekode).

Kilde: limits.ts (BBR_REST_MAX_COLD_SKIP).

count=true tæller op til 10 000

GraphQL-kilden har ingen optælling; count=true besvares ved at gennemløbe id’er og afvises med 400 over 10 000 objekter. Under grænsen er tallet det samme som REST’s (Læsø, Status=6: 5 899 begge steder).

Kilde: Paritetsfixture bygning-count-0825; limits.ts (BBR_REST_MAX_COUNT).

Indirekte filtre er begrænset til 5 000 objekter

Filtre der slås op via et andet objekt (BFENummer, Ejendomsrelation, Etage, Opgang, TekniskAnlaeg, Fordelingsareal, Jordstykke på grund, objektfiltrene på bbrsag) og Id-lister over 100 værdier hentes samlet og sorteres. Rammer de flere end 5 000 objekter, afvises forespørgslen med 400.

Kilde: limits.ts (BBR_REST_MAX_MATERIALISED).

Kun Format=JSON

Format=XML afvises med 400. JSON er standard, som i REST.

Kilde: params.ts.

Fejl som JSON

REST svarede fejl som ren tekst, fx "(400) Parameter: foo unrecognized". Her er fejl JSON: {"error": "...", "parameter": "foo"} med samme statuskode. Teksten nævner altid den parameter, der afvises — et filter ignoreres aldrig stiltiende.

Kilde: params.ts.

Grundfast-nøglen erstatter tjenestebrugeren

Nøglen kan sendes som password=… i URL’en (username ignoreres), som apiKey= eller token=, eller som header (Authorization: Bearer … / X-API-Key). Et kald er én enhed i forbruget uanset sidestørrelse.

Kilde: datafordeler-credential.middleware.ts.

Ingen reservekopi ved nedbrud

Svarene hentes live fra Datafordelerens GraphQL-tjeneste ved hvert kald. Er den nede eller for langsom, svares 502/503 — ligesom REST-tjenesten selv gjorde. Grundfasts egne /v1-endpoints har en reservekopi; dette kompatibilitetslag har ikke.

Kilde: datafordeler-bbr-rest.service.ts.