Søke etter dialoger
Hvordan søke etter og filtrere dialoger i Dialogporten
For bleeding edge, select "Dev", as this contains the most recent unreleased changes to the Dialogporten API. Select "Local dev" if you want to test changes to Dialogporten itself running locally.
Introduksjon
Denne veiledningen viser hvordan et sluttbrukersystem kan søke etter dialoger i Dialogporten ved hjelp av enten REST eller GraphQL APIer. Dialogporten støtter en rekke parametere for filtrering, sortering og fritekstsøk.
Merk at datastrukturen som returneres i søk er forskjellig fra den som returneres på detaljendepunktet; mer informasjon om dialogen og hvilken tilgang den autoriserte brukeren har til ulike deler av den er bare tilgjengelig i detaljvisningen.
Grunnleggende trinn (REST)
- Autentiser som en sluttbruker
- Finn partene som den autentiserte sluttbrukeren er autorisert til å representere
- Utfør en GET-forespørsel til
/api/v1/enduser/dialogs, og oppgi spørringsparametere i henhold til tabellen nedenfor:
- Alle parametere av forskjellige typer er AND-et, dvs. hvis du oppgir
partyogstatus, vil bare dialogene med den angitte statusen som eies av den angitte parten, returneres. - Når du støtter flere verdier for samme parameter, er disse verdiene OR-et, dvs. hvis du oppgir to
status-parametere, vil dialoger som har en av disse verdiene, returneres. org-parametere må være tjenesteeierkoder som definert i den globale altinn-orgs.json, f.eks.digdirellerskd.party-parametere må ha et av følgende formaterurn:altinn:person:identifier-no:<11 digit national identity numner>urn:altinn:organization:identifier-no:<9 digit CCR number>
serviceResource-parametere må referere til en ressurs i Ressursregisteret og bruke følgende format:urn:altinn:resource:<identifier>
serviceResource eller party parameter er oppgitt. Opptil 20 distinkte verdier for hver av disse to typene kan leveres.Returnert informasjon
Dette vil returnere en samling av dialoger, som inneholder et delsett av informasjonen som returneres på dialogdetaljendepunktet. Avhengig av søkeparametere og tilgangen til den autentiserte brukeren, kan denne listen være tom.
Hvis ugyldige søkeparametere oppgis, vil API-et returnere 400 Bad Request og et svar som forklarer hvilke feil som ble funnet. Dette svaret følger standard ProblemDetails formatet.
Paginasjon
Søke-APIet er paginert ved hjelp av fortsettelsestokens, se limit-parameteren ovenfor. Hvis det er flere sider som skal hentes, vil egenskapen hasNextPage settes til true, og egenskapen continuationToken fylles ut med en verdi som skal brukes til å hente neste side. For å hente neste side, oppgi den verdien som en continuationToken spørringsparameter. Dette vil opprettholde rekkefølgen og unngå manglende elementer eller å hente dem to ganger. Dette bør gjentas så lenge hasNextPage er true.
Sortering
Sortering kan utføres på følgende kolonner:
- CreatedAt
- UpdatedAt
- DueAt
Id er primærnøkkelkolonnen, er det også teknisk sett en sorterbar kolonne. Det anbefales imidlertid ikke å sortere etter Id fordi denne kolonnen, selv om den er en leksikografisk sorterbar UUIDv7, kan leveres av tjenesteeier eller inneholde en tidsstempledel som indikerer tidspunktet for migrering, ikke dialogoppretting. Så for de fleste formål er CreatedBy kolonnen du ønsker i stedet for Id.Kolonner kan sorteres i stigende og synkende (standard) rekkefølge, og flere kolonner kan leveres i OrderBy-kolonnen.
Eksempler
Dette er eksempelverdier som kan leveres i OrderBy-spørringsparameteren.
createdatcreatedat_asccreatedat_desc,duedate_asc
Gjeldende sortering finner du i collection model, ved siden av feltene continuationToken og hasNextPage. Sorteringen er også innebygd i continuationToken, så når du paginerer, er det tilstrekkelig å oppgi fortsettelsestoken alene for å bevare sorteringen.