Du kan be en KI om å bygge en app og raskt få skjemaer, sider og et API som ser ut til å fungere. Men hvilke data sender dette API-et? Får en ansatt bare opplysningene som trengs, eller havner hele brukerprofilen i nettleseren?
Denne guiden til DTO med KI tar utgangspunkt i en enkel situasjon: en leder og en ansatt bruker samme app, men trenger ulike opplysninger. Du lærer hva en DTO gjør, og fremfor alt hva du konkret bør be Codex, Claude eller Grok om for å få en løsning som passer prosjektet ditt.
Du trenger ikke pugge kompliserte definisjoner. Du må kunne beskrive hvem som ber om opplysningene, hva vedkommende har lov til å få, og hvordan du skal kontrollere resultatet.
DTO med KI: dette bør du forstå før du skriver prompten
Hva betyr DTO, enkelt forklart?
DTO står for Data Transfer Object: et objekt som brukes til å overføre data mellom deler av et system. I et API kan det beskrive formen på dataene som mottas eller sendes. Martin Fowler forklarer dette mønsteret som et objekt som frakter data og kan gjøres om til et format som sendes over et nettverk.
Tenk deg en intern saksmappe og to utdrag fra den. Mappen er informasjonskilden. Ett utdrag inneholder tre felt, det andre fem. Du oppretter verken to nye brukere eller to kontoer. Du lager to representasjoner av opplysninger om samme bruker.
En DTO kan implementeres som en klasse, en record eller en annen struktur som passer programmeringsspråket. Den konkrete formen avhenger av prosjektet. I første omgang er det listen over felter du definerer, som er viktig.
Entiteten, DTO-en og API-svaret
I eksempelet vårt er entiteten Bruker den interne modellen appen arbeider med. DTO-en beskriver dataene som er valgt ut for en bestemt utveksling. API-svaret er det klienten faktisk mottar, ofte som JSON.
Disse tingene henger sammen, men er ikke identiske. DTO-en må faktisk brukes når svaret bygges. At det finnes en klasse som heter UserDTO, endrer ikke automatisk hvilke data API-et sender.
Et enkelt eksempel: én bruker, to svar
Hva kan den ansatte se, og hva kan lederen se?
La oss anta at vi utvikler en intern app. Vi velger følgende fiktive regel: den ansatte kan se sin egen profil, mens lederen kan se profilene til medlemmene i sitt eget team.
| Felt | DTO for ansatt | DTO for leder |
|---|---|---|
| ID | Ja | Ja |
| Navn | Ja | Ja |
| Adresse | Ja, i dette eksempelet | Ja, i dette eksempelet |
| Jobb-e-post | Nei | Ja |
| Avdeling | Nei | Ja |
| Passordhash | Aldri | Aldri |
| Token for tilbakestilling av passord | Aldri | Aldri |
Adressen er med for å gjøre eksempelet lett å følge. Ta den bare med i din egen app dersom funksjonen trenger den og tilgangsreglene tillater det. En lederrolle gir ikke i seg selv tilgang til alle opplysninger om en person.
Hvorfor erstatter ikke DTO-en tilgangskontroll?
Tilgangskontrollen avgjør om en person kan få tilgang til en bestemt ressurs og bestemte felt. DTO-en beskriver formen på dataene appen sender etter at disse reglene er brukt.
En DTO med tre felt kan lekke opplysninger hvis den sendes til feil person. En ansatt skal for eksempel ikke kunne lese profilen til en annen ansatt bare ved å endre ID-en i adressen. OWASP beskriver dette som et eget problem med tilgangskontroll på objektnivå.
Det hjelper heller ikke å skjule et felt i grensesnittet. Hvis serveren sender det, kan det leses i API-svaret. OWASPs anbefalinger om tilgang til objektegenskaper sier at opplysningene som skal sendes til mottakeren, må velges uttrykkelig.
Fortell KI-en hva du bygger
Erstatt en vag bestilling med en konkret situasjon
«Lag noen DTO-er for brukere» lar mange avgjørelser stå åpne. KI-en vet ikke om du bygger en offentlig katalog, et internt kontrollpanel eller en app for flere organisasjoner. Klassenavnet forteller heller ikke hvem som bør kunne se adresser eller e-postadresser.
Begynn med formålet med funksjonen:
Jeg arbeider med en intern app for en bedrift. Vi har rollene ansatt og leder. Den ansatte ser sin egen profil. Lederen ser profilene til medlemmene i sitt eget team. Jeg vil ha ulike API-svar for disse situasjonene, med DTO-er eller en tilsvarende mekanisme som allerede finnes i prosjektet.
Nå beskriver bestillingen et resultat du kan observere. Du ber om en bestemt oppførsel i appen, i tillegg til selve kodeobjektet.
Gi kontekst om prosjektet
Med tilgang til koden eller i en vanlig samtale
Hvis assistenten har tilgang til prosjektet, viser du til den aktuelle modulen og ber den undersøke løsningen som finnes: brukermodellen, rutene, tilgangskontrollen og testene for funksjonen. Bruker du en chat uten filtilgang, legger du ved de relevante utdragene med fiktive data.
Du kan skrive:
Undersøk først hvordan API-svar og tilgangskontroll er bygget i dette prosjektet. Finn de relevante filene og følg eksisterende konvensjoner. Hvis du ikke har tilgang til koden, fortell meg nøyaktig hvilke utdrag jeg må gi deg. Ikke finn på en prosjektstruktur.
Den samme bestillingen kan brukes i Codex, Claude eller Grok. Hva assistenten faktisk kan utføre, avhenger av miljøet og verktøyene den har tilgjengelig. Et kodeeksempel i en chat betyr ikke at prosjektet ditt er endret eller testet.
Definer nøyaktig hvilke felt som er tillatt
Skriv en liste over feltene som skal tas med
«Skjul sensitive opplysninger» er for uklart. I ett prosjekt kan e-postadressen være offentlig; i et annet er den bare synlig for teamet. Oppgi hvilke felt som er godkjent i hvert svar.
Svaret til den ansatte skal inneholde nøyaktig: id, navn, adresse. Svaret til lederen skal inneholde nøyaktig: id, navn, adresse, jobbEpost, avdeling. Tilpass navnene til prosjektets konvensjoner. Ikke ta med andre egenskaper fra den interne modellen.
En slik liste hjelper deg å unngå en situasjon som ofte blir oversett: du legger senere til et nytt felt i modellen, og feltet dukker utilsiktet opp i svaret. I dette eksempelet skal det nye feltet holdes utenfor kontrakten til det er uttrykkelig godkjent.
Be om et eksempel på resultatet
Be om to eksempler med fiktive data før implementeringen. Kontroller at svaret til den ansatte bare har de tre feltene, og at svaret til lederen bare har de fem. Hvis KI-en automatisk legger til lønn, telefonnummer eller andre opplysninger, retter du kontrakten før du fortsetter.
Et lite eksempel gjør samtalen tydeligere enn en lang forklaring om «fullstendige data».
Presiser tilgangsreglene
Hvem ber om dataene, og hvem gjelder de?
Dette er to ulike spørsmål. I eksempelet vårt kan en innlogget ansatt be om sin egen profil. En leder kan be om profilen til et medlem av sitt eget team. At noen er leder, betyr ikke at vedkommende automatisk kan lese profiler i alle team.
Legg dette til i prompten:
Finn identiteten og rollen til den som sender forespørselen, fra appens verifiserte autentiseringsmekanisme. Kontroller tilgangen til den etterspurte brukeren. Ikke gi rettigheter basert på en rolleparameter fra klienten. Avvis tilgangen når reglene ikke tillater at profilen leses.
To endepunkter kan gjøre funksjonen oversiktlig, men navnene deres gir ingen rettigheter. En rute som inneholder ordet «leder», trenger fortsatt tilgangskontroll på serveren. Hvis appen allerede har en passende rute, er det ikke nødvendig å opprette to nye.
Be om en implementering som passer prosjektet
Hvordan havner dataene i DTO-en?
Å overføre interne data til feltene i svaret kalles ofte mapping. Appen kan for eksempel lese navnet fra modellen og sette det inn i det tilsvarende feltet i DTO-en.
Du kan be om to tydelige metoder for mapping, én for hver kontrakt. Men dette er ingen universell regel. Noen prosjekter bruker allerede mappere, serialiserere eller andre mekanismer for svar. Det viktige er at utvalget av felter er uttrykkelig og kan kontrolleres.
Implementer uttrykkelig mapping av de godkjente feltene. Bruk DTO-ene i de faktiske API-svarene, og behold prosjektets eksisterende skille mellom tilgangskontroll, applikasjonslogikk og bygging av svar. Unngå nye biblioteker eller omstruktureringer som denne endringen ikke trenger.
Skill mellom å lese og å endre data
En profil som API-et returnerer, og et skjema som sendes til API-et, har ikke nødvendigvis de samme feltene. At noen kan se avdelingen, betyr ikke at de kan endre den.
Hvis funksjonen inkluderer redigering av profilen, ber du om en egen kontrakt for inndata, med validering og tilgangskontroll for feltene som kan endres. Arbeider du bare med lesing, begrenser du oppgaven til svarene. Denne avgrensningen hjelper KI-en å holde implementeringen innenfor oppgaven.
Be om kontroller som kan dokumentere resultatet
Hva skal testene bevise?
For denne funksjonen bør nyttige tester kontrollere svarene og tilgangsreglene, i tillegg til at en DTO kan opprettes. Gi assistenten konkrete situasjoner:
- Den ansatte ber om sin egen profil og får nøyaktig de tre godkjente feltene.
- Den ansatte ber om en annen persons profil og blir nektet tilgang.
- Lederen ber om profilen til et teammedlem og får nøyaktig de fem godkjente feltene.
- Lederen ber om en profil utenfor sitt eget team og blir nektet tilgang.
- En forespørsel uten autentisering får ingen profildata.
- Endring av en rolleparameter i forespørselen gir ikke flere rettigheter.
- Passordhasher, tilbakestillingstokener og andre interne felt finnes ikke i svarene.
HTTP-koder og feilformat skal følge prosjektets kontrakt. Ikke krev en bestemt kode bare fordi den står i et eksempel, dersom appen din med hensikt bruker en annen oppførsel.
Be om dokumentasjon på kontrollene som er kjørt
Kjør de relevante kontrollene som er tilgjengelige i prosjektet. Oppgi til slutt hvilke kommandoer du kjørte, hvilke resultater du fikk, og hva du ikke kunne kontrollere. Si tydelig fra hvis du bare skrev tester uten å kjøre dem.
Et svar som sier «jeg har lagt til testene», beskriver en endring. Resultatet fra en testkjøring gir ytterligere dokumentasjon. Du må vite hva som faktisk er gjort.
Be om en forklaring du kan kontrollere
Hvordan vurderer du resultatet uten å være ekspert?
Etter implementeringen ber du om en kort forklaring av dataflyten: hvem sender forespørselen, hvor kontrolleres rettighetene, hvor velges feltene, og hvordan bygges svaret? Be også om hvilke filer som er endret, og hvorfor.
Forklar implementeringen med enkelt språk. Vis hvor tilgangen kontrolleres, og hvor feltene i svaret velges. Gi et eksempel for hver rolle og vis til testene som bekrefter oppførselen. Oppgi eventuelle forretningsmessige antakelser som fortsatt ikke er bekreftet.
Hvis forklaringen ikke stemmer med eksemplene på svar, ber du om en målrettet gjennomgang. Du trenger ikke forstå hver kodelinje for å oppdage at DTO-en for den ansatte inneholder et felt du ikke har godkjent.
En komplett prompt for Codex, Claude eller Grok
Kopier og tilpass bestillingen
Erstatt de fiktive reglene med reglene for appen din. Hvis du ikke har bestemt hvem som kan se et bestemt felt, må dette avklares før du ber om implementeringen.
Jeg vil implementere API-svar basert på DTO-er for brukerprofilene i den eksisterende appen.
Kontekst: Vi har rollene ansatt og leder. Den ansatte kan bare se sin egen profil. Lederen kan se profilene til medlemmene i sitt eget team. Dette er reglene for funksjonen vi bygger.
Kontrakt for ansatt: nøyaktig id, navn, adresse. Kontrakt for leder: nøyaktig id, navn, adresse, jobbEpost, avdeling. Bruk tilsvarende navn fra prosjektet. Passord, hasher, tilbakestillingstokener og andre interne data skal ikke returneres.
Undersøk den eksisterende implementeringen og følg prosjektets konvensjoner. Hvis du mangler filtilgang, be om de nødvendige utdragene. Finn autentiseringen, tilgangskontrollen, brukermodellen, byggingen av svar og de relevante testene.
Kontroller på serveren identiteten til den som spør, tilgangen til den etterspurte profilen og hvilke felt personen kan få. Ikke gi rettigheter basert på en rolle sendt fra klienten. DTO-en erstatter ikke tilgangskontroll.
Bygg de godkjente svarene uttrykkelig, med DTO-er eller en tilsvarende mekanisme som allerede finnes. Bruk dem i de faktiske endepunktene. Et felt som senere legges til i modellen, skal ikke automatisk dukke opp i svaret. Begrens endringen til denne funksjonen.
Test svarene for begge roller, uautorisert tilgang til andre profiler, forespørsler uten autentisering, forsøk på å endre rollen gjennom forespørselen og at interne felt ikke er med. Følg prosjektets feilformat.
Hvis du har arbeidstilgang til prosjektet, implementer løsningen og kjør relevante kontroller. Hvis du bare kan gi et forslag, si det tydelig. Oppgi til slutt filene som er endret, eksemplene på svar, kontrollresultatene og antakelsene som krever en avgjørelse fra meg.
Hvordan fortsetter du samtalen etter det første resultatet?
Bruk konkrete observasjoner: «E-postadressen er også med i svaret til den ansatte; fjern den fra kontrakten og kontroller den tilhørende testen» er mer nyttig enn «dette er feil». For en gjennomgang kan du be om: «Følg den faktiske veien til svaret og kontroller om noe sted returnerer den interne modellen direkte».
Formelen formål, kontekst, regler, eksempler og kontroller kan også brukes på bestillinger, reservasjoner eller fakturaer. Tydelig kontekst og klare kriterier finnes i OpenAIs guide til arbeid med Codex, i Anthropics anbefalinger for Claude og i xAIs guide for Grok. Prompten ovenfor er vårt eksempel på hvordan dette kan brukes til DTO-er.
Vanlige spørsmål om DTO-er og KI
Må jeg kunne programmere for å be en KI om DTO-er?
Du kan begynne med å definere rollene, feltene og eksemplene på svar. For å vurdere implementeringen trenger du kontroller og noen som kan gjennomgå koden når endringen går utover det du selv forstår.
Er DTO-en en ny tabell i databasen?
Nei. Å opprette en DTO betyr ikke automatisk å opprette en tabell. Den beskriver data som overføres. Ikke be om en databasemigrering bare fordi du trenger et annet API-svar.
Trenger man alltid to DTO-er for to roller?
Nei. Eksempelet bruker to kontrakter for å gjøre forskjellen tydelig. I et reelt prosjekt kan kontraktene organiseres etter funksjon eller brukstilfelle. Flere roller kan bruke samme kontrakt når reglene tillater det.
Beskytter DTO-en opplysningene på egen hånd?
Nei. Utvalget av data må kombineres med tilgangskontroll. Kontroller både hvem som kan få svaret, og hvilke opplysninger svaret inneholder.
Kan jeg bruke samme prompt i Codex, Claude og Grok?
Ja, forretningskravene er de samme. Tilpass konteksten du gir og oppgavene du ber om, til assistentens faktiske tilgang: en samtale, vedlagte filer eller et miljø som er koblet til prosjektet.
Hva gjør jeg hvis KI-en sier at implementeringen er ferdig?
Be om eksempler på svar og resultater fra kontrollene som er kjørt. Sammenlign dem med reglene dine. En bekreftelse erstatter ikke kontroll av hvordan appen oppfører seg.
Begynn med dataene du vil sende
For å samarbeide tydeligere med KI-en beskriver du først resultatet: hvem ber om dataene, hvilken profil kan personen se, og hvilke felt kan personen få? Be deretter om implementeringen og dokumentasjon på at den følger reglene.
DTO-er er et godt eksempel på denne arbeidsmåten: en teknisk idé blir enklere å bestille når du gjør den om til konkrete regler og resultater som kan kontrolleres.