Mens jeg har holdt på å fikse Nikita-implementasjonen til å bli mer
robust og komplett, så har jeg observert at det finnes tre mekanismer
implementert i Nikta for å oppdatere registrert arkivinformasjon.
PUT
---
Her forventes det at en skal hente først med GET, endre felt og verdier
en ønsker å endre, fjerne _links (med mindre en ønsker flytte
oppføringen) og så gjøre PUT mot samme endepunkt. Jeg tror alle
endepunkter nå støtter PUT, men det er mangelfull håndtering av
feltsletting og forsøk på endring av verdier som ikke kan endres. Så
vidt jeg kan forstå vil forsøk på å endre skrivebeskyttede verdier i dag
ignoreres og sletting av tekst/tall-felt ignoreres, mens sletting av
metadata-felt fører til intern feil i Nikita. N5TG spesifiserer denne,
og dette var opprinnelig metode i N5TG for oppdatering av informasjon
via API-et. Her må API-mottaket sammenligne innsendt informasjon med
informasjonen i arkivet for å finne ut om et felt skal oppdateres eller
ikke.
PATCH med JSON-instrukser (RFC 6902)
------------------------------------
Her gir en instrukser i JSON-format (add/move/etc) om hva en ønsker
endre, som så gjennomføres av Nikita. Dette er ikke tilgjengelig for
alle endepunkt, og så vidt jeg kan se har den ikke god kontroll med
hvilke felt som er skrivebeskyttet og hvilke som kan oppdateres. Med
bruken av PATCH er det kun informajson om felt som skal endres som
sendes over, hvilket gjør det enklere for mottaker å vite intensjon.
Mekanismen var en kandidat til å komme inn i N5TG, og ble implementert i
Nikita for å teste ut dette, men ble til slutt valgt bort til fordel for
PATCH med JSON merge-last (RFC 7396)
------------------------------------
Her gir en JSON-format med de feltene som skal erstattes, tilordner dem
'null' hvis de skal slettes, og nikita oppdaterer så aktuelle felt.
Dette er tilgjengelig for alle endepunkt og har så vidt jeg kan se god
kontroll over skrivbarhetsstatus og sletting av felt. Denne mekanismen
er lagt til N5TG som et alternativ til N5TG til bruk av PUT. Også her
er det enklere å forstå intensjon med en endringsforespørsel enn PUT.
Anbefaling
----------
Jeg tenker det er opphav til kaos å ha flere ulike mekanismer for å
oppdatere informasjon i arkivet, spesielt når det er ulike
implementasjoner med potensielt litt forskjellig oppførsel. JEg tenker
det også gjør livet vanskeligere for API-klienter som må forholde seg
til flere mulige mekanikker og ikke nødvendigvis vet hvilken som bør
brukes når.
Jeg tenker derfor at oppdatinging ved bruk av PATCH med JSON-instrukser
RFC 6902 og PUT bør droppes fra både Nikita og N5TG, slik at det kun er
en mekanisme igjen og vi kan konsentere innsatsen om å gjøre denne så
robust og korrekt som mulig.
Jeg tenker videre at selv om N5TG fortsatt nevner PUT som en mulighet,
så bør Nikita dokumentere at denne muligheten ikke eksisterer i Nikita
og at en i stedet må bruke PATCH i tråd med RFC 7396 for alle endringer.
Det kan ta litt tid å få PUT ut av N5TG, men jeg tror Nikita ikke bør
vente på dette før en reduserer kodebase og angrepsflate ved å fjerne
PUT-støtte.
Hva tenker dere andre?
--
Vennlig hilsen
Petter Reinholdtsen