Oversikt over REST. Del 1: Hva er REST? I denne delen skal vi dykke dypt ned i hvordan kommunikasjon foregår mellom klient og server. Underveis vil vi avdekke nye begreper og forklare dem. For å sikre at alt er klart, vil vi analysere klient-server-kommunikasjon ved å bruke en RESTful-applikasjon som eksempel. Anta at vi utvikler en nettapplikasjon som lagrer informasjon om kunder og deres bestillinger. Med andre ord, systemet vårt er i stand til å utføre operasjoner på visse enheter: opprette, redigere og slette dem, og vise informasjon om dem. Disse enhetene vil være:
kunder (kunder)
bestillinger (kundebestillinger)
varer (produkter)
I en RESTful-arkitektur sender klienter forespørsler til en server for å hente eller endre data, og deretter sender servere klienter svar på forespørslene deres.
Forespørsler
Klientforespørsler gjøres nesten alltid ved hjelp av HTTP-protokollen. Generelt består HTTP-forespørsler av flere komponenter:
HTTP-metoden
Overskrift
URI
forespørselsorgan
Nedenfor vil vi vurdere hver komponent i større detalj.
URIer og ressurser
Dataene som klienter mottar eller endrer gjennom forespørsler, kalles ressurser. Klient-server-kommunikasjon handler om å manipulere ressurser. I REST er ressurser alt du kan gi navn til. På en måte er de som klasser i Java. I Java kan vi lage en klasse for hva som helst. Så i REST kan en ressurs være hva som helst: en bruker, et dokument, en rapport, en ordre. Det kan enten være en abstraksjon av en enhet, eller noe spesifikt, for eksempel et bilde, video, animasjon eller PDF-fil. I vårt eksempel har vi 3 ressurser:
kunder (kunder)
bestillinger (kundebestillinger)
varer (produkter)
Klienter sender forespørsler til ressursplasseringer kjent som endepunkter. Enkelt sagt er et endepunkt som en adresse på nettverket. Dykker vi dypere kan vi si at et endepunkt er en URI, dvs. en sekvens av tegn som identifiserer en abstrakt eller fysisk ressurs. Uniform Resource Identifier (URI) Noen ganger kalles et endepunkt, eller URI, en bane, som betyr banen til en ressurs. I denne artikkelen vil vi bruke begrepet URI. Hver spesifikk ressurs må ha en unik URI. Serverutvikleren er ansvarlig for at hver ressurs alltid har sin egen URI. I vårt eksempel er vi utviklerne, så vi vil gjøre det slik vi vet hvordan. Akkurat som det ofte er vanlig å tilordne numeriske identifikatorer som primærnøkler i en relasjonsdatabase, har hver ressurs også sin egen ID i REST. Ressurs-ID-en i REST samsvarer ofte med ID-en til posten i databasen som lagrer informasjon om ressursen. REST URIer starter vanligvis med flertallsformen av et substantiv som beskriver en ressurs. For eksempel, "
/customers — URI for alle tilgjengelige kunder
/customers/23 — URI til en spesifikk kunde, dvs. kunden med ID=23
/customers/4 — URI til en spesifikk kunde, dvs. kunden med ID=4.
Men det er ikke alt. Vi kan utvide URI ved å legge til bestillinger:
/customers/4/orders — URI for alle bestillinger gjort av kunde nr. 4
/customers/1/orders/12 — URI for ordre nr. 12 laget av kunde nr. 1.
Hvis vi fortsetter utvidelsen ved å legge til flere produkter, får vi:
/customers/1/orders/12/items — URI for listen over alle produkter i ordre nr. 12 laget av kunde nr. 1.
Når vi legger til nivåer av hekking, er det viktige å gjøre URI-ene intuitive.
HTTP-metoden
HTTP-metoden er en sekvens av alle tegn (unntatt kontrolltegn og skilletegn), som indikerer hovedoperasjonen som utføres på ressursen. Det er flere vanlige HTTP-metoder. Vi vil liste opp de som brukes oftest i RESTful-tjenester:
GET — Få informasjon om en bestemt ressurs (gjennom dens ID) eller om en samling av ressurser
POST — Opprett en ny ressurs
PUT — Endre en ressurs (gjennom dens ID)
SLETT – Slett en ressurs (via dens ID)
Overskrifter
Forespørsler, så vel som svar, inneholder HTTP-hoder. De formidler tilleggsinformasjon om forespørselen (eller svaret). Overskrifter er nøkkelverdi-par. Du kan se listen over de vanligste overskriftene på Wikipedia . Når det gjelder REST, sender klienter ofte en "Accept" header i forespørsler til serveren. Denne overskriften er nødvendig for å fortelle serveren hvilket format klienten forventer å motta et svar i. Ulike formater er gitt i en liste over MIME-typer. MIME (Multipurpose Internet Mail Extensions) er en spesifikasjon for koding av informasjon og formatering av meldinger slik at de kan sendes over Internett. Hver MIME-type består av to deler atskilt med en skråstrek - en type og undertype. Eksempler på MIME-typer for forskjellige filtyper:
For eksempel kan en forespørsel ha en overskrift som dette:
Accept:application/json
Denne overskriften forteller serveren at klienten forventer å motta et svar i JSON-format.
Forespørselsinstans
Dette er meldingen som sendes av klienten til serveren. Hvorvidt forespørselen har en kropp eller ikke, avhenger av typen HTTP-forespørsel. For eksempel inneholder GET- og DELETE-forespørsler vanligvis ingen forespørselstekst. Men PUT- og POST-forespørsler kan - det avhenger bare av formålet med forespørselen. Tross alt, for å motta og/eller slette data ved hjelp av en ID (som sendes i URL-en), trenger du ikke å sende ytterligere data til serveren. Men for å opprette en ny ressurs (gjennom en POST-forespørsel), må du sende ressursen. Det samme gjelder for å endre en eksisterende ressurs. I REST sendes forespørselsteksten oftest i XML- eller JSON-format. JSON-formatet er mest vanlig. Anta at vi ønsker å sende en forespørsel til serveren for å opprette en ny ressurs. Hvis du ikke har glemt, vi vurderte eksempelet på en applikasjon som administrerer kundeordrer. La oss si at vi ønsker å opprette en ny kunde. I vårt tilfelle lagrer vi følgende kundeinformasjon: Navn, e-post, telefonnummer. Da kan brødteksten i forespørselen være følgende JSON:
Rediger kunde nr. 1 som følger:
Navn — Ben
E-post — bigben@jr.com
Telefonnummer — +86 (868) 686-8686
DELETE /customers/12/orders/6
Slett ordre nr. 6 laget av kunde nr. 12 fra systemet
Svar
La oss si noen ord om serversvar. Et svar består vanligvis av følgende deler:
svarkode
overskrifter
responskropp
Generelt er ikke svarhoder mye forskjellig fra forespørselshoder. I tillegg brukes noen overskrifter i både svar og forespørsler. Jeg tror også alt er klart angående forespørselsorganet. Organet returnerer ofte informasjon etterspurt av klienten. Informasjon som returneres som svar på GET-forespørsler kan også være i JSON-format. Men den siste delen er litt mer interessant.
HTTP-svarkoder
La oss vurdere HTTP-svarkoder mer detaljert. En HTTP-statuskode er en del av den første linjen i et serversvar på forespørsler gjort via HTTP-protokollen. Det er et heltall som består av tre desimaler. Det første sifferet angir klassen for svarstatuskoden. Svarkoden etterfølges vanligvis av en forklarende setning på engelsk, atskilt med et mellomrom. Denne setningen er en menneskelig lesbar grunn til svaret. Eksempler:
201 Opprettet
401 Uautorisert
507 Utilstrekkelig lagringsplass
Svarkoden forteller klienten resultatet av forespørselen og lar den bestemme hvilke handlinger som skal utføres videre. Svarkoder er delt inn i flere klasser eller grupper:
1XX — Informasjon
2XX — Disse kodene indikerer at klientens forespørsel ble mottatt og behandlet
3XX — Disse kodene informerer klienten om at en tilleggsforespørsel, vanligvis til en annen URI, må gjøres for å fullføre operasjonen
4XX — Klientfeil. Slike koder kan være et resultat av en feilkomponert forespørsel. Et annet eksempel er den velkjente "404 Not Found"-koden, som kan oppstå når en klient ber om en ikke-eksisterende ressurs
5XX — Serverfeil. Disse kodene returneres til klienten hvis serveren er ansvarlig for feil i operasjonen
For å sikre at alt er klart, vil vi analysere klient-server-kommunikasjon ved å bruke en RESTful-applikasjon som eksempel. Anta at vi utvikler en nettapplikasjon som lagrer informasjon om kunder og deres bestillinger. Med andre ord, systemet vårt er i stand til å utføre operasjoner på visse enheter: opprette, redigere og slette dem, og vise informasjon om dem. Disse enhetene vil være:
GO TO FULL VERSION