Når man opretter f.eks. en faktura via REST-API’et, så er der en del felter der kræver unikke identifikationsnumre: customer-objektet skal have et customerNumber, deliveryLocations skal have et deliveryLocationNumber osv.
Men når først fakturaen er oprettet, så bruges disse numre ikke rigtig til noget synligt. Alle oplysninger om kunder, leveringssteder, varer osv. er bare tomme på fakturaen. Eller, det vil sige næsten alle, for der er nogle enkelte oplysninger der faktisk hentes ind som man kunne forvente: kundens CVR-nummer (men uden landepræfiks, for landet hentes ikke med) og betalingsbetingelsen (beskrivelse + udregnet betalingsfrist).
Men de fleste af de oplysninger der hentes automatisk ind når man vælger kunde, leveringssted, produkt osv. i browseren, kommer ikke med. For at få dem med, skal man først lave individuelle GET-kald til hvert af de enkelte endpoints for at hente oplysninger, udvælge de relevante felter fra hvert enkelt svar, og så sende de udvalgte felter med som underfelter i POST-kaldet man sender af sted for at oprette en faktura. Det vil sige at oprettelse af en faktura ikke er ét API-kald men snarere ti, alt afhængig af hvor mange fakturalinjer der er.
Hvorfor i alverden er API’et dog lavet sådan?
Hvis jeg sender et kald af sted hvor kundeoplysninger kun er defineret som "customer": { "customerNumber": 12345 }, så er det da intet andet end forventeligt at jeg ønsker at kunde 12345’s kundeoplysninger skal fremgå af fakturaen. Det er sådan alle andre REST-API’er jeg nogensinde har brugt til at oprette fakturaer/posteringer/ordrer, fungerer, og det er sådan et REST-API bør fungere. Man giver et identifikationsnummer, og så lægges de relevante data ind på ordren.
Det er fint nok at man har muligheden for at medsende oplysninger manuelt hvis man gerne vil override de oplysninger der ligger gemt på kunden, men det bør være frivillige felter til overrides – ikke påkrævede felter for overhovedet at få noget ind på fakturaen.
Jeg ved fra tidligere forespørgsler at der ikke længere udvikles på nuværende version af REST-API’et, men at der på et tidspunkt (forhåbentlig i dette årti) kommer et opdateret API der forhåbentlig fungerer bedre end det nuværende, så jeg gør mig ingen forhåbninger om at dette bliver ændret.
Men jeg håber inderligt at det nye API, hvis det nogensinde kommer, bliver lavet på en måde der svarer mere til almindelig REST-praksis på dette punkt.