Page Comparison

...

• Etape 1: IT-Systemer (i kataloget) og Snitflader https://os2web.atlassian.net/browse/KITOSUDV-63

• Etape 2: IT-Systemer i kommunen https://os2web.atlassian.net/browse/KITOSUDV-1928

• Etape 3: Databehandling https://os2web.atlassian.net/browse/KITOSUDV-1949

• Etape 4: Kontrakter https://os2web.atlassian.net/browse/KITOSUDV-1950

• Etape 5: Delta-Feed https://os2web.atlassian.net/browse/KITOSUDV-2041

• Etape 6: PATCH i høj opløsning https://os2web.atlassian.net/browse/KITOSUDV-2358

...

• POST: Oprettelse af nye ressourcer

• GET: Hente eksisterende ressourcer

• PUT: Eksisterende version af ressource opdateres med nye data

• PATCH: Delvis opdatering af en eksisterende ressource

  • Bemærk: Indtil https://os2web.atlassian.net/browse/KITOSUDV-2358 er leveret, vil “opløsningen” af PATCH opdateringer være grovkornet. Se mere herom i sektionen https://os2web.atlassian.net/wiki/spaces/KITOS/pages/2059599873/API+Design+V2#PUT-og-PATCH .

• DELETE: Ressourcen nedlægges

...

I første omgang tilbydes rettelser via anvendelse af PUT og i begrænset omfang via PATCH.

I PUT leveres alt data til den nye version af ressourcen. Dette betyder at udfylder man ikke et valgfrit felt i json dokumentet der sendes ifm. PUT, så nulstiller KITOS data for dette felt. Da data kan have været opdateret i KITOS anbefales det derfor at skrive ændringer via API via følgende protokol:

• GET ressourcen, der skal ændres via GET api/v2/{ressource-type}/{uuid}

• Flet data fra den seneste version fra KITOS med ændringer der skal skrives

• PUT resultatet af fletningen.

På et senere tidspunkt kan det, hvis det giver mening, komme på tale at understøtte PATCH, hvor enkelte felter kan opdateres individuelt fra de andre. Kontakt gerne KITOS sekretariatet hvis du mener, at du har et sådant behov. Udviklingsopgaverne prioriteres ikke såfremt der ikke er efterspørgsel efter et mere fingranuleret opdaterings-api.Når PATCH anvendes er det for at muliggøre opdatering af en delmængde af ressourcen dvs. man skal i denne sammenhæng ikke levere en fuld opdatering men kan nøjes med at opdatere den del af data som er relavant.

Begrænsninger i PATCH

I første omgang tilbydes PATCH med begrænset opløsning, hvor valgfriheden tilbydes på “rod-niveau”. Dette er eksemplificeret nedenfor:

Udgangspunktet er følgende, komplette, datakontrakt:

{
  "name": "a name",
  "general" : {
      "enabled": false,
      "localId": "a local id"
  },
  "parentUuid" : "CF397900-4550-4E6C-A2AC-C329BBBB7475"
}

Scenario 1: Opdatering af “name”

“name” er et felt på “rod-niveau” dvs. det ligger i roden af datakontrakten, og derfor kan det opderes 100% uafhængigt af andre felter:

PATCH /api/v2/{ressouce}/{uuid}
{
  "name": "a new name"
}

Ovenstående payload vil resultere i en opdatering af “name” og kun “name”.

Scenario 2: Opdatering af “localId”

For localId bemærkes at dette ligger på en sektion i roden “general” men at det ligger på linje med andre felter som forventes leveret i samme request. Derfor vil følgende request være korrekt:

PATCH /api/v2/{ressouce}/{uuid}
{
  "general" : {
      "enabled": {current_enabled_state_fetched_Before_patch},
      "localId": "a new local id"
  }
}

Udelades “enabled” fra requestet, vil KITOS nulstille dette felt til standardværdien.

Scenario 3: Opdatering af “name” og parentUuid

Opdatering af flere felter i roden af kontrakten fungerer på linje med opdatering af et enkelt felt. Man kan derfor formulere følgende request:

PATCH /api/v2/{ressouce}/{uuid}
{
  "name": "a new name",
  "parentUuid" : "B47C7EF7-E7B3-4FD5-B7B8-B4C4CA78BBD9"
}

Derved vil kun “name” og “parentUuid” blive opdateret, og sektionen “general”, og alle data herunder, vil forblive uberørt.

Scenario 4: Nulstilling af sektioner/felter

Såfremt feltet optræder på rodniveau, vil det blive evalueret, så hvis der f.eks. leveres “null” til “general”, så vil det blive opfattet som “nulstilling af general-sektionen og alle data herunder”.

PATCH /api/v2/{ressouce}/{uuid}
{
  "general" : null
}

Forretningsreglerne er stadig gældende

...