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?