Bygge Web Tjenester REST Vei

On By admin

Original English version: http://xfront.com/REST-Web-Services.html 

Roger L. Costello

Jeg vil først gi en kort introduksjon til hvile og deretter beskrive hvordan å bygge webtjenester i resten stil.

Hva er REST?

REST er et begrep skapt av Roy Fielding i sin Ph.D. avhandling [1] for å beskrive en arkitektur stil av nettverkssystemer. REST er et akronym som står for Representational State Transfer.

Hvorfor heter det Representational State Transfer?

Nettet består av ressurser. En ressurs er et element av interesse. For eksempel kan Boeing Aircraft Corp definere en 747 ressurs. Klienter kan få tilgang til den ressursen med denne nettadressen:

http://www.boeing.com/aircraft/747

En representasjon av ressursen blir returnert (f.eks Boeing747.html). Representasjonen plasserer klientapplikasjon i en tilstand. Resultatet av klienten traversering en hyperlink i Boeing747.html er en annen ressurs er tilgjengelig. Den nye representasjons plasserer klientprogrammet inn i enda en stat. Således klientapplikasjonen endringer (overføring s) tilstand med hver ressurs representasjon -> Representational State Transfer! Her er Roy Fielding forklaring på betydningen av Representational State Transfer: “Representational State Transfer er beregnet til å fremkalle et bilde på hvordan et godt utformet Web-applikasjon oppfører: et nettverk av websider (en virtuell state-maskin), hvor brukeren utvikler seg gjennom et program ved å velge koblinger (tilstandsoverganger), noe som resulterer i den neste side (som representerer den neste tilstand av søknaden) som overføres til brukeren og gjort for deres anvendelse.”

Motivasjon for REST

Motivasjonen for REST var å fange egenskapene til Web som gjorde Web vellykket. Deretter disse egenskapene blir brukt til å lede utviklingen av Internett.

REST – en arkitektonisk stil, ikke en standard

REST er ikke en standard. Du vil ikke se W3C sette ut en REST-spesifikasjonen. Du vil ikke se IBM eller Microsoft eller Sun selger en REST utviklers verktøykasse. Hvorfor? Fordi resten er bare en arkitektonisk stil. Du kan ikke flaske opp den stilen. Du kan bare forstå det, og designe dine webtjenester i den stilen. (. Analogt til klient-server arkitektonisk stil Det er ingen klient-server-standarden.) Mens resten er ikke en standard, det gjør bruk standarder:

  • HTTP
  • URL
  • XML / HTML / GIF / JPEG / etc (Resource Representations)
  • text / xml, tekst / html, bilde / gif, image / JPEG, etc (MIME-typer)

Classic REST System

Nettet er et REST system! Mange av disse web-tjenester som du har brukt så mange år – book-bestilling av tjenester, søketjenester, online ordbok tjenester, etc – er REST-baserte webtjenester. Alas, du har brukt REST, bygge REST-tjenester og du ikke engang vet det. REST er opptatt av det “store bildet” i Nett. Det handler ikke om gjennomføringen detaljer (f.eks, ved hjelp av Java servlets eller CGI for å gjennomføre en webtjeneste). Så la oss se på et eksempel på å skape en webtjeneste fra resten “store bildet” perspektiv.

Deler Depot Web Services

Deler Depot, Inc (fiktivt selskap) har utplassert noen webtjenester å aktivere sine kunder til å:

  • få en liste over deler
  • få detaljert informasjon om en bestemt del
  • sende en innkjøpsordre (PO)

La oss vurdere hvordan hver av disse tjenestene er implementert i en rolig måte.

Få Parts List

Web-tjenesten gjør tilgjengelig en URL til en deleliste ressurs. For eksempel vil en klient bruke denne nettadressen for å få listen deler:

http://www.parts-depot.com/parts

Merk at “hvordan” webtjenesten genererer delelisten er helt transparent for klienten. Alt kunden vet er at hvis han/hun sender inn nettadressen ovenfor da et dokument som inneholder en liste over deler returneres. Siden innføringen er transparent for klienter, er deler Depot fritt til å endre den underliggende implementeringen av denne ressursen uten å påvirke kunder. Dette er løs kobling. Her er dokumentet som kunden mottar:

<? Xml version = "1.0"?>
<P: Deler xmlns: p = "http://www.parts-depot.com" 
         xmlns: XLink = "http://www.w3.org/1999/xlink">
      <Part id = "00345" XLink: href = "http://www.parts-depot.com/parts/00345" />
      <Part id = "00346" XLink: href = "http://www.parts-depot.com/parts/00346" />
      <Part id = "00347" XLink: href = "http://www.parts-depot.com/parts/00347" />
      <Part id = "00348" XLink: href = "http://www.parts-depot.com/parts/00348" />
</ P: Deler>

[Anta at gjennom innholdet forhandlinger tjenesten bestemt at kunden ønsker representasjon som XML (for maskin-til-maskin-behandling).] Merk at delelisten har koblinger for å få detaljert informasjon om hver del. Dette er en viktig funksjon i REST. Klient overføringer fra en tilstand til den neste ved å undersøke og velge blant alternative nettadresser i responsen dokumentet.

Få Detaljert del data

Web-tjenesten gjør tilgjengelig en URL til hver del ressurs. Eksempel her er hvordan en kunde ber del 00345:

http://www.parts-depot.com/parts/00345

Her er dokumentet som kunden mottar:

<? Xml version = "1.0"?>
<P: Dele xmlns: p = "http://www.parts-depot.com"   
        xmlns: XLink = "http://www.w3.org/1999/xlink">
      <Part-ID> 00345 </ Part-ID>
      <Name> widget-A </ Name>
      <Beskrivelse> Denne delen er brukt i sammenstillingen frap </ Beskrivelse>
      <Spesifikasjon XLink: href = "http://www.parts-depot.com/parts/00345/specification" />
      <UnitCost valuta = "USD"> 0,10 </ UnitCost>
      <Mengde> 10 </ Mengde>
</ P: Part>

Igjen observere hvordan disse dataene er knyttet til enda mer data – spesifikasjonen for denne delen kan finnes ved å gå gjennom hyperkoblingen. Hvert svar dokument lar klienten å bore ned for å få mer detaljert informasjon.

Send PO

Web-tjenesten gjør tilgjengelig en URL for å sende inn en PO. Klienten oppretter en PO eksempel dokument som er i samsvar med PO-skjema som deler Depot har laget (og offentliggjort i en WSDL-dokument). Klienten sender PO.xml som nyttelast på en HTTP POST.

PO-tjenesten svarer på HTTP POST med en URL til innsendt PO. Dermed kan kunden hente PO helst senere (for å oppdatere/redigere det). Den PO er blitt et stykke informasjon som er delt mellom klienten og serveren. Den delte informasjonen (PO) er gitt en adresse (URL) av serveren og er eksponert som en webtjeneste.

Logiske webadresser versus Fysiske webadresser

En ressurs er en konseptuell enhet. En representasjon er et konkret manifestasjon av ressursen. Denne nettadressen:

http://www.parts-depot.com/parts/00345

Er en logisk URL, ikke en fysisk URL. Dermed gjør det ikke trenger å være, for eksempel en statisk HTML-side for hver del. Faktisk, hvis det var en million deler deretter en million statiske HTML-sider ikke ville være en svært attraktiv design. [Gjennomføring detalj: Deler Depot kunne gjennomføre tjenesten som får detaljerte data om en bestemt del ved å ansette en Java Servlet som analyserer strengen etter vertsnavn, bruker delenummeret for å søke på deler database, formulere spørringsresultatene som XML, og deretter returnere XML som nyttelast på HTTP-svaret.] som et spørsmål om webadresser stil bør ikke avsløre gjennomføringen teknikk som brukes. Du må stå fritt til å endre implementeringen uten å påvirke kunder eller å ha villedende nettadresser.

REST Web Services Kjennetegn

Her er kjennetegnene på REST:

  • Klient-Server: en pull-basert samhandling stil: forbruker komponenter trekke representasjoner.
  • Tilstandsløs: hver forespørsel fra klient til server må inneholde all nødvendig informasjon for å forstå forespørselen, og kan ikke dra nytte av eventuelle lagret sammenheng på serveren.
  • Buffer: for å forbedre nettverkseffektiviteten reaksjoner må være i stand til å bli merket som hurtiglagerbare eller ikke-hurtiglagerbare.
  • Uniform grensesnitt: alle ressurser er tilgjengelige med et generisk grensesnitt (for eksempel HTTP GET, POST, PUT, DELETE).
  • Navngitte ressurser – systemet består av ressurser som er oppkalt bruker en nettadresse.
  • Sammenkoplede ressursrepresentasjoner – representasjoner av ressursene er sammenkoblet ved hjelp av nettadresser, og dermed muliggjør en klient for å gå fra en tilstand til en annen.
  • Lagdelte komponenter – formidlere, som for eksempel proxy-servere hurtiglagringstjenere, gateways, etc., kan innsettes mellom klienter og ressurser for å støtte ytelse, sikkerhet, etc.

Prinsipper for REST Web Service Design

1. Nøkkelen til å skape Web Services i en REST-nettverk (dvs. Web) er å identifisere alle de konseptuelle enheter som du ønsker å eksponere som tjenester. Ovenfor så vi noen eksempler på ressurser: liste over deler, detalj del data, innkjøpsordre.
2. Opprett en URL til hver ressurs. Ressursene bør være substantiver, ikke verb. For eksempel ikke bruke denne:

http://www.parts-depot.com/parts/getPart?id=00345

Merk verbet, getPart. I stedet bruker et substantiv:

http://www.parts-depot.com/parts/00345

3. Kategorisere dine ressurser i henhold til om kundene kan bare motta en representasjon av ressursen, eller om klienter kan endre (legge til) ressursen. For det første, gjør disse ressursene tilgjengelig via en HTTP GET. For senere, gjør disse ressursene tilgjengelig ved hjelp av HTTP POST, PUT, og/eller DELETE. 4. Alle ressurser som er tilgjengelige via HTTP GET bør være bivirkning gratis. Det er, bør ressursen bare returnere en representasjon av ressursen. Starte ressursen bør ikke føre til endring av ressursen. 5. Ingen mann/kvinne er en øy. Likeledes bør ingen representasjon være en øy. Med andre ord, sette hyperlinker i ressursrepresentasjoner for å muliggjøre klientene å bore ned for mer informasjon, og/eller for å innhente relevant informasjon.6. Design å avsløre data gradvis. Ikke avslør alt i ett enkelt svar dokument. Gi hyperkoblinger for å få flere detaljer. 7. Angi formatet av responsdata ved å bruke et skjema (DTD, W3C Schema, RelaxNG, eller Schematron). For de tjenester som krever en POST eller sette til det, også gi et skjema til å angi formatet av responsen. 8. Beskriv hvordan tjenestene skal startes ved hjelp av enten en WSDL-dokument, eller rett og slett et HTML-dokument.

Sammendrag

Denne artikkelen beskrev REST som en arkitektonisk stil. Faktisk er det den arkitektoniske stilen på nettet. REST beskriver hva som gjør nettet fungerer bra. Hvis man følger resten prinsippene vil gjøre dine tjenester fungerer bra i sammenheng med Internett. I en fremtidig artikkel vil jeg skrive om utviklingen av Internett via REST prinsipper.

Bekreftelse

Takk til Robert Leftwich og Philip Eskelin for sine svært nyttige kommentarer i å skape dette dokumentet.