Uavhengig av hvordan konseptet klient-tjener-arkitektur er definert (og det er mange slike definisjoner i litteraturen), er grunnlaget for dette konseptet en distribuert databehandlingsmodell. I det mest generelle tilfellet, under klient Og server to samvirkende prosesser er forstått, hvorav den ene er en leverandør av en tjeneste for den andre.

Begrepet "klient-server" betyr en arkitektur av en programvarepakke der funksjonelle deler samhandler i henhold til "request-response"-skjemaet. Hvis vi vurderer to samvirkende deler av dette komplekset, utfører en av dem (klienten) en aktiv funksjon, det vil si at den initierer forespørsler, og den andre (serveren) svarer passivt på dem. Etter hvert som systemet utvikler seg, kan rollene endres, for eksempel vil noen programvareblokker samtidig utføre funksjonene til en server i forhold til en blokk og en klient i forhold til en annen.

Server - en eller flere flerbrukerprosessorer med et enkelt minnefelt, som, i samsvar med brukerens behov, gir dem funksjonene for beregning, kommunikasjon og tilgang til databaser. Server kan kalles et program som gir noen tjenester til andre programmer. Eksempler på servere er Apache-webserveren, databaseservere - MySQL, ORACLE, nettverksfilsystemer og Windows-skrivere.

Klient - arbeidsstasjon for en bruker, å gi registreringsmodus og andre funksjoner som er nødvendige på arbeidsplassen hans - beregninger, kommunikasjon, tilgang til databaser, etc. En klient kan kalles et program som bruker tjenesten levert av serverprogrammet. Klienteksempler - MSIE (MS Internet Explorer), ICQ-klient.

Ofte refererer folk ganske enkelt til datamaskinen som ett av disse programmene kjører på som en klient eller server.

I hovedsak er klient og server roller, kjørbare programmer. Klienter og servere kan fysisk ligge på samme datamaskin. Det samme programmet kan være både en klient og en server samtidig, osv... dette er bare roller.

Hvis vi trekker en analogi med samfunnet - en bank eller en butikk - "servere". De tilbyr noen tjenester til sine kunder. Men banken kan samtidig være klient i et annet selskap osv...

Klient-server-behandling er et miljø der applikasjonsbehandling er fordelt mellom en klient og en server. Maskiner er ofte involvert i prosessering forskjellige typer, og klienten og serveren kommuniserer med hverandre ved å bruke et fast sett med standard utvekslingsprotokoller og prosedyrer for tilgang til eksterne plattformer.

DBMS med personlige datamaskiner(som Clipper, DBase, FoxPro, Paradox, Clarion har nettverksversjoner som ganske enkelt deler databasefiler med de samme formatene for PC-en, mens de implementerer nettverkslåser for å begrense tilgangen til tabeller og poster. I dette tilfellet utføres alt arbeid på PC-en. Serveren brukes ganske enkelt som en delt ekstern disk stor kapasitet. Denne måten å jobbe på fører til risiko for tap av data på grunn av maskinvarefeil.

Sammenlignet med slike systemer har systemer bygget i Client-Server-arkitekturen følgende fordeler:

lar deg øke størrelsen og kompleksiteten til programmer som kjører på en arbeidsstasjon;


sikrer overføring av de mest arbeidskrevende operasjonene til en server, som er en maskin med større datakraft;


minimerer muligheten for tap av informasjon i databasen gjennom bruk av interne databeskyttelsesmekanismer som er tilgjengelige på serveren, som for eksempel transaksjonssporingssystemer, tilbakeføring etter en feil og midler for å sikre dataintegritet;


reduserer mengden informasjon som overføres over nettverket flere ganger.


I en klient-tjener-arkitektur gir databaseserveren ikke bare tilgang til delte data, men håndterer også all behandling av disse dataene. Klienten sender forespørsler til serveren om å lese eller endre data, som er formulert i SQL. Serveren selv gjør alle nødvendige endringer eller valg, mens den overvåker integriteten og konsistensen til dataene, og sender resultatene i form av et sett med poster eller en returkode til klientens datamaskin.


Den lar deg fordele databelastningen optimalt mellom klienten og serveren, noe som også påvirker mange egenskaper ved systemet: kostnad, ytelse, støtte.


1.2. Historie…


Arkitekturen og begrepet "klient-server" ble først brukt på begynnelsen av 80-tallet. De første applikasjonene med klient-server-arkitektur var databaser.


Før dette var det ingen klar inndeling – programmet gjorde som regel alt selv – inkludert å jobbe med data i filsystem, presentasjon av data til brukeren osv. Over tid vokste volumet og kritikaliteten til data for virksomheten, og dette begynte over tid å gi opphav til problemer (ytelse, sikkerhet og annet).


Så fant de ut at det ville være praktisk å installere databasen på en kraftig separat datamaskin(server) og la denne databasen brukes av mange små databrukere (klienter) over nettverket, noe som ble gjort.


I hovedsak ble "eksplosjonen" i populariteten til klient-server-teknologi forårsaket av IBMs oppfinnelse av et enkelt spørrespråk relasjonsdatabaser SQL-data. I dag er SQL den universelle standarden for arbeid med databaser. Nylig fortsatte denne "eksplosjonen" med oppfinnelsen av Internett, der bokstavelig talt hver interaksjon skjer i henhold til en "klient-server"-arkitektur.


1.3. Protokoller


Serveren og klienten på nettverket "snakker" med hverandre på et "språk" (i vid forstand av ordet) som er forståelig for begge parter. Dette "språket" kalles en protokoll.


Når det gjelder en bank, kan protokollen kalles skjemaene som klienten fyller ut.


I vårt tilfelle, eksempler på protokoller:


FTP ( Filoverføring protokoll)


HTTP (Hyper Text Transfer Protocol)


SMTP (Simple Mail Transfer Protocol)


IP (internettprotokoll)


MySQL Client/Server Protocol


Merk at protokoller kan være ulike nivåer. Klassifiseringssystemer av nivåer kan være forskjellige, men en av de mest kjente linjene er OSI (Open Systems Interconnection), som har 7 nivåer.


For eksempel er HTTP en applikasjonsprotokoll (syvende - høyeste) lagprotokoll, og IP er en nettverksprotokoll (tredje) lag.


1.4. Distribusjon av funksjoner i klient-server-arkitekturen


I klassisk arkitektur Klient-serveren må distribuere de tre hoveddelene av applikasjonen over to fysiske moduler. Vanligvis er datalagringsprogramvare plassert på en server (for eksempel en databaseserver), brukergrensesnittet er på klientsiden, men databehandling må fordeles mellom klient- og serverdelen. Dette er den største ulempen med tolagsarkitekturen, hvorfra flere ubehagelige funksjoner, som i stor grad kompliserer utviklingen av klient-server-systemer.


Utviklingsprosessen til slike systemer er ganske kompleks, og en av de viktigste oppgavene er beslutningen om hvordan funksjonaliteten til applikasjonen skal fordeles mellom klient- og serverdelen. For å prøve å løse dette problemet, får utviklere to-lags, tre-lags og multi-lag arkitekturer. Alt avhenger av hvor mange mellomkoblinger som er inkludert mellom klienten og serveren.


Hovedproblemet det løser klientapplikasjon, gir et grensesnitt med brukeren, det vil si å legge inn data og presentere resultater i en brukervennlig form, og administrere applikasjonsscenarier.


Hovedfunksjonene til en server-DBMS er å sikre pålitelighet, konsistens og sikkerhet for data, administrere klientforespørsler og rask behandling av SQL-spørringer.


Hele logikken til applikasjonen - applikasjonsoppgaver, forretningsregler - i en tolagsarkitektur fordeles av utvikleren mellom to prosesser: klient og server (fig. 1).


Til å begynne med ble de fleste av applikasjonens funksjoner løst av klienten, serveren var kun involvert i å behandle SQL-spørringer. Denne arkitekturen kalles "tykk klient - tynn server".


Fremveksten av muligheten til å lage lagrede prosedyrer på serveren, det vil si kompilerte programmer med intern driftslogikk, har ført til en tendens til å overføre en økende del av funksjonene til serveren. Serveren ble mer og mer "feit", og klienten ble "tynnere".


Denne løsningen har åpenbare fordeler, for eksempel er det lettere å vedlikeholde, fordi alle endringer må gjøres på bare ett sted - på serveren.


Modellene diskutert ovenfor har følgende ulemper.


1. "Tykk" klient:


– kompleksiteten i administrasjonen;


– oppdatering av programvaren blir mer komplisert, siden den må byttes ut samtidig over hele systemet;


– maktfordelingen blir mer komplisert, siden tilgangen ikke begrenses av handlinger, men av tabeller;


- nettverket er overbelastet på grunn av overføring av ubehandlede data gjennom det;


– svak databeskyttelse, siden det er vanskelig å fordele fullmakter på riktig måte.


2. "Fet"-server:


– implementeringen blir mer komplisert, siden språk som PL/SQL ikke er egnet for å utvikle slik programvare og det er ingen gode midler feilsøking;


– ytelsen til programmer skrevet på språk som PL/SQL er betydelig lavere enn de som er laget på andre språk, som har viktig for komplekse systemer;


- programmer skrevet på DBMS-språk fungerer vanligvis ikke pålitelig; en feil i dem kan føre til feil på hele databaseserveren;


– de resulterende programmene er fullstendig uportable til andre systemer og plattformer.


For å løse disse problemene brukes klient-serverarkitekturer på flere nivåer (tre eller flere nivåer). lagdelt arkitektur klient-server lar deg betydelig forenkle distribuert databehandling, noe som gjør den ikke bare mer pålitelig, men også mer tilgjengelig.


Språket som lagrede prosedyrer er skrevet på er imidlertid ikke kraftig eller fleksibelt nok til å enkelt implementere kompleks applikasjonslogikk.


Så var det en tendens til å betro utførelsen av applikasjonsoppgaver og forretningsregler til en separat applikasjonskomponent (eller flere komponenter), som kan kjøres enten på en spesielt dedikert datamaskin - applikasjonsserveren, eller på samme datamaskin som databaseserveren kjører . Dette er hvordan tre-lags og flerlags klient-server-arkitekturer dukket opp.





Ris. 1. Fordeling av funksjoner mellom klient og server


Det var en spesiell programvare Mellomvare (programvare) som må tillate flere komponenter i en slik flerkomponentapplikasjon å fungere sammen. Slike applikasjoner er fleksible, skalerbare, men vanskelige å utvikle.



BIBLIOGRAFI

1. Informatikk / Ed. N.V. Makarova. – M.: Finans og statistikk, 1998.
   

   Evdokimov V.V. og andre Økonomisk informatikk. St. Petersburg: Peter, 2004.
   

   Kazakov S.I. Grunnleggende nettverksteknologier– M.: Radio og kommunikasjon, 2004.
   

   Kogalovsky M.R., Databaseteknologi på personlige datamaskiner, - M.: Finance and Statistics, 2003.
   

   Popov V.V. Grunnleggende om datateknologi. –M.: Finans og statistikk, 2001.
   

   Figurnov V.E. IBM PC for brukeren. M., 2000.
   

OPERATIVSYSTEM MS-DOS. GRUNNLEGGENDE KONSEPT OG KOMMANDOER GRUNNLEGGENDE KONSEPT: DATABASE, DBMS, ENTITET, ATRIBUTE, RELASJON (EN-TIL-EN, EN-TIL-MANGE, MANGE-TIL-MANGE), RELASJON, PRIMÆRNØKKEL

DB-er som bruker FILSERVER-teknologi;

DB-er som bruker CLIENT-SERVER-teknologi.

Filserver

- Tilgang til databasen (spørring)
- Overføring av data mens du blokkerer tilgang til andre brukere
- Databehandling på brukerens datamaskin

For klarhet, la oss vurdere spesifikke eksempler. La oss si at du må se sendte betalingsordrer for perioden fra 19. mai til 25. mai til et beløp på 5 000 rubler. Brukeren må starte en klientapplikasjon på sin datamaskin som fungerer i databasen med betalingsordrer, og angi de nødvendige utvalgskriteriene. Deretter vil den lastes ned til datamaskinen din fra databaseserveren og lastes inn i RAM en fil som inneholder alle dokumenter av denne typen for hele perioden for eventuelle beløp. En klientapplikasjon som kjører på brukerens datamaskin som fungerer med databasen vil behandle denne informasjonen (sortere den ut) og deretter gi et svar (en liste over betalingsordrer som oppfyller kriteriene dine vises på skjermen). Etter dette vil du velge ønsket betalingsordre og prøve å redigere (endre) ett felt i det - for eksempel datoen. Under redigering blokkeres datakilden, det vil si hele filen som inneholder dette dokumentet. Dette betyr at filen enten ikke vil være tilgjengelig for andre brukere i det hele tatt, eller bare vil være tilgjengelig i visningsmodus. Dessuten forekommer denne typen fangst ikke engang på rekordnivå, det vil si ett dokument, men hele filen er låst - det vil si hele tabellen som inneholder lignende dokumenter. Først etter at dette feltet er ferdig behandlet og redigeringsmodusen er avsluttet, vil denne betalingsordrefilen låses opp fra å bli fanget opp av brukeren. Hvis dataene er lagret i større objekter, for eksempel, inneholder én fil betalingsoppdrag for både mottak av midler og sending av midler, vil enda mer av informasjonen ikke være tilgjengelig. Du vil jobbe med ett "dato"-felt i ett dokument - resten av bedriftens ansatte vil vente til du er ferdig.

Ulempene med FILSERVER-systemet er åpenbare:

Veldig stort press på nettet, økte krav til båndbredde. I praksis gjør dette det nesten umulig å jobbe samtidig stort nummer brukere med store datamengder.

Databehandling utføres på brukernes datamaskin. Dette medfører økte maskinvarekrav for hver bruker. Jo flere brukere, jo mer penger vil måtte brukes på å utstyre datamaskinene deres.

Låsing av data ved redigering av én bruker gjør det umulig for andre brukere å jobbe med disse dataene.

Sikkerhet. For å kunne jobbe med et slikt system, må du gi hver bruker full tilgang til hele filen, der han kan være interessert i bare ett felt.

Klient server

Behandler en enkelt brukerforespørsel:
- Tilgang til databasen (SQL-spørring)
- Overføring av svaret - resultatet av behandlingen




Hvis det er nødvendig å behandle informasjon som er lagret i databasen, genererer en klientapplikasjon som kjører på brukerens datamaskin som jobber med databasen en spørring i SQL-språket (navn fra startbokstavene - Structured Query Language). Databaseserveren godtar forespørselen og behandler den uavhengig. Ingen datamatrise (fil) overføres over nettverket. Etter å ha behandlet forespørselen, overføres bare resultatet til brukerens datamaskin - det vil si i forrige eksempel en liste over betalingsordrer som oppfyller de nødvendige kriteriene. Selve filen, der dataene som fungerte som kilde for behandling ble lagret, forblir ublokkert for tilgang av serveren selv på forespørsel fra andre brukere.

I seriøse klient-tjener DBMS er det ekstra mekanismer, redusere belastningen på nettverket, redusere krav til brukerdatamaskiner. Som et eksempel vil vi gi lagrede prosedyrer - det vil si hele programmer for behandling av data lagret i databasen. I dette tilfellet overføres ikke engang SQL-uttrykk fra brukeren til serveren - et funksjonskall med kalleparametere overføres. Dermed, arbeidsplass brukeropplevelsen forenkles ytterligere, logikken til programmet overføres til serveren. Brukerplassen blir bare et middel for å vise informasjon. Alt dette betyr en ytterligere reduksjon i belastningen på nettverket og brukerarbeidsstasjonene.

Altså alt de ovennevnte ulempene FIL-SERVER-skjemaer er eliminert i CLIENT-SERVER-arkitekturen:

Datamatriser overføres ikke over nettverket fra databaseserveren til brukerens datamaskin. Kravene til nettverksbåndbredde reduseres. Dette gjør det mulig for et stort antall brukere å jobbe samtidig med store datamengder.

Databehandling utføres på databaseserveren, og ikke på brukerens datamaskin. Dette tillater bruk av enklere, og derfor billigere, datamaskiner på klientsidene.

Data blir ikke blokkert (fanget opp) av én bruker.

Brukeren gis ikke tilgang til hele filen, men kun til data fra den som brukeren har rett til å arbeide med.

Etter å ha vurdert forskjellen mellom en FILSERVER og en KLIENTSERVER, kan vi fullføre vår vurdering av konseptet "informasjonslagring". Det er viktig å understreke at driften av bedriftssystemet i stor grad avhenger av typen DBMS som brukes. Det er helt åpenbart at for store bedrifter, med stort beløp brukere, med stort antall poster i databasen, er filserverordningen fullstendig uakseptabel. På den annen side er det forskjeller i databaser i andre parametere og muligheter:

typer data som kan lagres i databasen (tall, datoer, tekst, bilder, video, lyd osv.);

på teknologier organisert av selve databasen for å få tilgang til data i databasen og nivået på informasjonsbeskyttelse mot uautorisert tilgang;

på de medfølgende utviklingsverktøyene og metodene som kan brukes til å designe ethvert informasjonssystem basert på denne databasen;

på de medfølgende verktøyene og metodene for å analysere informasjon (data), som kan brukes i et informasjonssystem basert på denne databasen;

når det gjelder pålitelighet og stabilitet, det vil si (omtrent) antall poster (utfylte felt) i databasen, som sikrer en pålitelig og uavbrutt mulighet til å få tilgang til, endre og analysere informasjon i databasen;

etter hastighet - tid brukt på å få tilgang til og behandle informasjon;

hvis mulig, organiser arbeidet på datamaskiner forskjellige produsenter, det vil si kompatibilitet med andre plattformer og operativsystemer;

av nivået på støtte (tjeneste) levert av databaseutvikleren eller dens autoriserte forhandler;

på tilgjengeligheten av gode verktøy for å lage applikasjoner som bruker denne databasen data osv.

Hvorfor er det ikke lønnsomt å investere i en filserverløsning i dag? I dag er den fremtidige veien for databaseutvikling allerede åpenbar. Multi-level klient-server-systemer dukker opp, med svært tynne klienter, som fjerner eventuelle begrensninger fra klientstasjoner, både når det gjelder ytelse og plattform og operativsystem. Hvis for en klient-server-løsning videre utvikling virker helt klar, og overgangen fra en klient-server til en multi-level klient-server er ikke problematisk, så for en filserver representerer en enkel overgang til en klient-server et stort problem og enorme arbeidskostnader, hvis dette plutselig snur ut til å være mulig i det hele tatt.

Vladimir, nettutvikler hos Noveo, sier:

De fleste utviklere av nettsider, webtjenester og mobilapplikasjoner må før eller siden forholde seg til klient-server-arkitektur, nemlig utvikle et web-API eller integrere med det. For ikke å finne opp noe nytt hver gang, er det viktig å utvikle en relativt universell tilnærming til web API-design, basert på erfaringen med å utvikle lignende systemer. Vi gjør deg oppmerksom på en kombinert serie med artikler viet til denne saken.

Tilnærming en: Tegn

På et tidspunkt, i prosessen med å lage en annen nettjeneste, bestemte jeg meg for å samle all min kunnskap og tanker om temaet å designe et web-API for å betjene behovene til klientapplikasjoner og sette det i form av en artikkel eller en serie med artikler. Min erfaring er selvfølgelig ikke absolutt, og konstruktiv kritikk og tillegg er mer enn velkommen.

Lesningen viste seg å være mer filosofisk enn teknisk, men for fans av den tekniske delen vil det være noe å tenke på. Jeg tviler på at jeg i denne artikkelen vil si noe fundamentalt nytt, noe du aldri har hørt om, lest eller tenkt på selv. Prøver bare å få med alt enhetlig system, først av alt, i ditt eget hode, og dette er allerede verdt mye. Likevel vil jeg være glad hvis mine tanker vil være nyttige for deg i din praksis. Så la oss gå.

Klient og server

Server i dette tilfellet vurderer vi en abstrakt maskin på nettverket som er i stand til å motta en HTTP-forespørsel, behandle den og returnere riktig svar. I sammenheng med denne artikkelen er dens fysiske essens og interne arkitektur helt uviktig, enten det er en student-laptop eller en stor klynge av industrielle servere spredt rundt om i verden. På samme måte spiller det ingen rolle for oss hva som er under panseret, hvem som tar imot forespørselen ved døren, Apache eller Nginx, hvilket ukjent beist, PHP, Python eller Ruby som behandler det og genererer et svar, hvilken datalagring som brukes : Postgresql, MySQL eller MongoDB . Hovedsaken er at serveren oppfyller hovedregelen - å høre, forstå og tilgi.

Klient det kan også være alt som er i stand til å generere og sende en HTTP-forespørsel. Inntil et visst punkt i denne artikkelen vil vi heller ikke være spesielt interessert i målene som klienten setter for seg selv når han sender denne forespørselen, og heller ikke hva han vil gjøre med svaret. Klienten kan være et JavaScript-skript som kjører i nettleseren, mobilapp, en ond (eller ikke så ond) demon som kjører på serveren, eller et for klokt kjøleskap (det finnes allerede slike ting).

For det meste vil vi snakke om kommunikasjonsmetoden mellom de to ovennevnte, på en slik måte at de forstår hverandre, og ingen av dem har noen spørsmål.

REST Filosofi

REST (Representational state transfer) ble opprinnelig tenkt som et enkelt og entydig grensesnitt for databehandling, som bare involverte noen få grunnleggende operasjoner med direkte nettverkslagring (server): datahenting (GET), lagring (POST), modifikasjon (PUT/PATCH). ) og sletting (SLETT). Denne listen ble selvfølgelig alltid ledsaget av alternativer som behandlingsfeil i forespørselen (er forespørselen satt sammen riktig), begrense tilgangen til data (plutselig burde du ikke vite dette) og validering av innkommende data (plutselig skrev du tull), i generelt, av alle mulige kontroller, som serveren utfører før det oppfyller ønsket klient.

I tillegg har REST en rekke arkitektoniske prinsipper, en liste over disse finnes i en hvilken som helst annen artikkel om REST. La oss gå gjennom dem kort slik at de er for hånden og du ikke trenger å gå hvor som helst:

Serverens uavhengighet fra klienten- servere og klienter kan umiddelbart erstattes av andre uavhengig av hverandre, siden grensesnittet mellom dem ikke endres. Serveren lagrer ikke klientstatuser.
Unikhet til ressursadresser- hver enhet med data (uavhengig av nestinggrad) har sin egen unike URL, som faktisk er helt og holdent en unik ressursidentifikator.

Eksempel: GET /api/v1/users/25/name

Uavhengighet av datalagringsformatet fra overføringsformatet- serveren kan støtte flere ulike formater for å overføre de samme dataene (JSON, XML, etc.), men lagrer dataene i sitt interne format, uavhengig av hvilke som støttes.

Tilstedeværelse av alle nødvendige metadata i svaret- i tillegg til selve dataene, må serveren returnere detaljer om forespørselsbehandling, for eksempel feilmeldinger, ulike ressursegenskaper nødvendig for videre arbeid med det, for eksempel, det totale antallet poster i samlingen for å vise pagineringsnavigasjon på riktig måte. Vi vil gå over de forskjellige ressurstypene senere.

Hva mangler vi?

Classic REST innebærer at klienten jobber med serveren som et flatt datalager, mens ingenting sies om tilkoblingen og gjensidig avhengighet av data seg imellom. Alt dette faller som standard helt på skuldrene til klientapplikasjonen. Moderne fagområder som databehandlingssystemer er utviklet for, det være seg sosiale tjenester eller online markedsføringssystemer, innebærer imidlertid et komplekst forhold mellom enhetene som er lagret i databasen. Støtter disse forbindelsene, dvs. dataintegritet er serversidens ansvar, mens klienten kun er et grensesnitt for å få tilgang til disse dataene. Så hva mangler vi i REST?

Funksjonsanrop

For ikke å endre dataene og forbindelsene mellom dem manuelt, kaller vi ganske enkelt en funksjon på ressursen og "mater" de nødvendige dataene til den som et argument. Denne operasjonen passer ikke til REST-standardene, det er ikke noe spesielt verb for den, som tvinger oss, utviklere, til å komme oss ut av veien.

Det enkleste eksempelet– brukerautorisasjon. Vi kaller påloggingsfunksjonen, sender den et objekt som inneholder legitimasjon som et argument, og mottar en tilgangsnøkkel som svar. Vi bryr oss ikke om hva som skjer med dataene på serversiden.

Et annet alternativ– skape og bryte forbindelser mellom data. For eksempel å legge til en bruker i en gruppe. Ringer enheten gruppe addUser-funksjonen, sender et objekt som en parameter bruker, får vi resultatet.

Og også Det er operasjoner som ikke er direkte relatert til lagring av data som sådan, for eksempel å sende varsler, bekrefte eller avvise eventuelle operasjoner (gjennomføring av rapporteringsperioden osv.).

Flere operasjoner

Det skjer ofte, og klientutviklere vil forstå hva jeg mener, at det er mer praktisk for en klientapplikasjon å lage/endre/slette/flere homogene objekter på en gang med en forespørsel, og for hvert objekt er det mulig med en annen dom på serversiden. . Det er minst flere alternativer her: enten er alle endringer fullført, eller de er delvis fullført (for noen objekter), eller det har oppstått en feil. Vel, det er også flere strategier: bruk endringer bare hvis alle lykkes, eller bruk delvis, eller rulle tilbake i tilfelle feil, og dette fører allerede til en fullverdig transaksjonsmekanisme.

For et web-API som streber etter idealitet, vil jeg også på en eller annen måte bringe slike operasjoner inn i systemet. Jeg skal prøve å gjøre dette i en av oppfølgerne.

Statistiske spørringer, aggregatorer, dataformatering

Det hender ofte at vi, basert på data som er lagret på serveren, må få en statistisk oppsummering eller data formatert på en spesiell måte: for eksempel for å bygge en graf på klientsiden. I hovedsak er dette data generert på forespørsel, mer eller mindre på farten, og er skrivebeskyttet, så det er fornuftig å legge det inn egen kategori. En av særegne trekk statistiske data, etter min mening, er at de ikke har en unik ID.

Jeg er sikker på at dette ikke er alt man kan møte når man utvikler ekte applikasjoner, og jeg vil gjerne se dine tillegg og justeringer.

Datatyper

Objekter

Nøkkeldatatypen i kommunikasjon mellom klient og server er et objekt. I hovedsak er et objekt en liste over egenskaper og deres tilsvarende verdier. Vi kan sende et objekt til serveren i en forespørsel og motta forespørselsresultatet som et objekt. I dette tilfellet vil ikke objektet nødvendigvis være en reell enhet lagret i databasen, men i det minste, i den formen den ble sendt eller mottatt i. For eksempel sendes autorisasjonslegitimasjon som et objekt, men er ikke en uavhengig enhet. Til og med objekter som er lagret i databasen, har en tendens til å skaffe tilleggsegenskaper av intrasystemnatur, for eksempel datoer for opprettelse og redigering, ulike systemetiketter og flagg. Objektegenskaper kan enten være deres egne skalarverdier eller inneholde relaterte objekter Og samlinger av gjenstander, som ikke er en del av objektet. Noen objektegenskaper kan redigeres, noen er systemegenskaper, skrivebeskyttet, og noen kan være statistiske i naturen og beregnes umiddelbart (for eksempel antall likes). Noen objektegenskaper kan være skjult, avhengig av brukerens rettigheter.

Samlinger av gjenstander

Når vi snakker om samlinger, mener vi en type serverressurs som lar deg jobbe med en liste over homogene objekter, dvs. legge til, slette, endre objekter og velge fra dem. I tillegg kan en samling teoretisk sett ha sine egne egenskaper (for eksempel maksimalt antall elementer per side) og funksjoner (jeg er forvirret her, men dette skjedde også).

Skalære verdier

I sin rene form har skalarverdier som en separat enhet vært ekstremt sjeldne i mitt minne. Vanligvis har de dukket opp som egenskaper ved gjenstander eller samlinger, og som sådan kan de leses eller skrives. For eksempel kan brukernavnet hentes og endres individuelt med GET /users/1/name . I praksis er denne funksjonen sjelden nyttig, men om nødvendig vil jeg gjerne ha den for hånden. Dette gjelder spesielt for samlingsegenskaper, for eksempel antall poster (med eller uten filtrering): GET /news/count .

I en av de følgende artiklene vil jeg prøve å klassifisere disse operasjonene og tilby alternativer mulige forespørsler og svar basert på hvilke jeg møtte i praksis.

Tilnærming to: Den rette veien

I denne tilnærmingen vil jeg snakke separat om tilnærminger for å bygge unike veier til ressurser og metoder for web-API og om de arkitektoniske funksjonene til applikasjonen som påvirker utseende denne banen og dens komponenter.

Hva du bør tenke på når du står på kysten

Versjonskontroll

Før eller siden begynner ethvert operativsystem å utvikle seg: utvikle seg, bli mer komplekst, skalere og bli mer moderne. For REST API-utviklere er dette først og fremst fylt med behovet for å lansere nye versjoner av API mens de gamle kjører. Her snakker jeg ikke lenger om arkitektoniske endringer under panseret på systemet ditt, men om det faktum at selve dataformatet og settet med operasjoner med det endrer seg. I alle fall må versjonering gis som i den opprinnelige organisasjonen kildekode, og i prinsippet URL-konstruksjon. Når det gjelder URL-er, er det to mest populære måter å indikere versjonen av API-en som forespørselen er adressert til. Prefiks for eksempel-api.com/v1/-banen og separering av versjoner på v1.example-api.com-underdomenenivå. Du kan bruke hvilken som helst av dem, avhengig av dine behov og krav.

Autonomi av komponenter

Web-API-en til komplekse systemer som støtter flere brukerroller krever ofte oppdeling i deler, som hver tjener sitt eget utvalg av oppgaver. Faktisk kan hver del være frittstående applikasjon, jobbe med forskjellige fysiske maskiner og plattformer. I sammenheng med å beskrive API er det slett ikke viktig for oss hvordan serveren behandler forespørselen og hvilke krefter og teknologier som er involvert i dette. For klienten er API-en et innkapslet system. Ulike deler av systemet kan imidlertid ha helt ulik funksjonalitet, for eksempel administrasjons- og brukerdelen. Og metodikken for å jobbe med tilsynelatende de samme ressursene kan variere betydelig. Derfor må slike deler skilles på nivået til admin.v1.example-api.com-domenet eller example-api.com/v1/admin/-baneprefikset. Dette kravet er ikke obligatorisk, og mye avhenger av kompleksiteten til systemet og dets formål.

Datautvekslingsformat

Det mest praktiske og funksjonelle, etter min mening, datautvekslingsformatet er JSON, men ingen forbyr bruk av XML, YAML eller noe annet format som lar deg lagre serialiserte objekter uten å miste datatypen. Om ønskelig kan du gjøre det i API-støtte flere input/output formater. Det er nok å bruke HTTP-forespørselsoverskriften for å indikere ønsket Accept-responsformat og Content-Type for å indikere formatet på dataene som overføres i forespørselen. Til andre populær måte er å legge til en utvidelse til ressurs-URLen, for eksempel GET /users.xml , men denne metoden virker mindre fleksibel og vakker, om ikke annet fordi den gjør URL-en tyngre og er mer sann for GET-forespørsler enn for alle mulige operasjoner.

Lokalisering og flerspråklighet

I praksis handler API-flerspråklighet oftest om å oversette tjeneste- og feilmeldinger til det nødvendige språket for direkte visning til sluttbrukeren. Flerspråklig innhold har også sin plass, men lagring og utgivelse av innhold videre forskjellige språk, etter min mening, bør differensieres tydeligere, for eksempel hvis du har den samme artikkelen på forskjellige språk, så er dette faktisk to forskjellige enheter, gruppert basert på innholdets enhet. Ulike metoder kan brukes for å identifisere det forventede språket. Den enkleste er standard HTTP-header Accept-Language. Jeg har sett andre måter, for eksempel å legge til en GET-parameter language="en" , bruke baneprefikset example-api.com/en/ , eller til og med på domenenavnnivået en.example-api.com . Det virker for meg at valget om hvordan du skal spesifisere lokaliteten avhenger av den spesifikke applikasjonen og oppgavene den står overfor.

Intern ruting

Så vi har nådd rotnoden til API-en vår (eller en av dens komponenter). Alle videre ruter vil passere direkte inne i din serverapplikasjon, i henhold til settet med ressurser den støtter.

Samlingsveier

For å spesifisere banen til samlingen bruker vi ganske enkelt navnet på den tilsvarende enheten, for eksempel hvis dette er en liste over brukere, vil banen være /brukere. To metoder gjelder for samlingen som sådan: GET (motta en begrenset liste over enheter) og POST (opprette et nytt element). I forespørsler om lister kan vi bruke mange ekstra GET-parametere som er vant til sideutgang, sortering, filtrering, søking etc, men de må være valgfrie, dvs. disse parameterne må ikke sendes som en del av banen!

Samlingselementer

For å få tilgang til et bestemt element i samlingen bruker vi det i ruten unik identifikator/brukere/25 . Dette er den unike veien til det. For å jobbe med et objekt er metodene GET (å skaffe et objekt), PUT/PATCH (endre) og DELETE (slette) gjeldende.

Unike gjenstander

Mange tjenester har objekter som er unike for gjeldende bruker, for eksempel gjeldende brukers profil /profil , eller personlige innstillinger /innstillinger . Selvfølgelig, på den ene siden, er disse elementer i en av samlingene, men de er utgangspunktet for bruken av vår Web API av klientapplikasjonen, og tillater også et mye bredere spekter av operasjoner på data. Samtidig er samlingen lagring egendefinerte innstillinger er kanskje ikke tilgjengelig i det hele tatt på grunn av sikkerhets- og personvernårsaker.

Egenskaper til gjenstander og samlinger

For å komme direkte til noen av egenskapene til et objekt, er det nok å legge egenskapsnavnet til banen til objektet, for eksempel få brukernavnet /brukere/25/navn . Metodene GET (å få en verdi) og PUT/PATCH (endre en verdi) kan brukes på en egenskap. DELETE-metoden er ikke aktuelt fordi en egenskap er en strukturell del av et objekt, som en formalisert enhet av data.

I forrige del snakket vi om at samlinger, i likhet med gjenstander, kan ha sine egne egenskaper. Min erfaring er at den eneste egenskapen jeg har funnet nyttig er count-egenskapen, men søknaden din kan være mer kompleks og spesifikk. Baner til samlingsegenskaper bygges etter samme prinsipp som egenskapene til elementene deres: /users/count . For samlingseiendommer er kun GET-metoden (å få en egenskap) aktuelt, siden en samling er bare et grensesnitt for å få tilgang til en liste.

Samlinger av relaterte objekter

Én type objektegenskap kan være relaterte objekter eller samlinger av relaterte objekter. Slike enheter er som regel ikke et objekts egen eiendom, men refererer bare til dets forbindelser med andre enheter. For eksempel en liste over roller som ble tildelt brukeren /users/25/roles. Vi vil snakke i detalj om arbeid med nestede objekter og samlinger i en av de følgende delene, og videre sånn som det er nå Det er nok for oss at vi har muligheten til å få tilgang til dem direkte, som enhver annen egenskap til et objekt.

Funksjoner av gjenstander og samlinger

For å bygge banen til funksjonskallgrensesnittet til en samling eller et objekt, bruker vi samme tilnærming som for å få tilgang til en egenskap. For eksempel for /users/25/sendPasswordReminder-objektet eller /users/disableUnconfirmed-samlingen. For funksjonskall bruker vi alltid POST-metoden. Hvorfor? La meg minne deg på at i klassisk REST er det ikke noe spesielt verb for å kalle funksjoner, og derfor må vi bruke en av de eksisterende. Etter min mening er POST-metoden best egnet for dette fordi... det lar deg sende de nødvendige argumentene til serveren, er ikke idempotent (returnerer det samme resultatet når du får tilgang til flere ganger), og er det mest abstrakte innen semantikk.

Jeg håper at alt passer mer eller mindre inn i systemet :) I neste del skal vi snakke mer detaljert om forespørsler og svar, deres formater og statuskoder.

Tilnærming tre: Spørsmål og svar

I tidligere tilnærminger snakket jeg om hvordan ideen kom til å samle og oppsummere den eksisterende erfaringen innen web-API-utvikling. I den første delen prøvde jeg å beskrive hvilke typer ressurser og operasjoner på dem vi forholder oss til når vi designer et web-API. Den andre delen berørte spørsmålene om å konstruere unike URL-er for tilgang til disse ressursene. Og i denne tilnærmingen vil jeg prøve å beskrive de mulige alternativene for forespørsler og svar.

Universelt svar

Vi har allerede sagt at det spesifikke formatet for kommunikasjon mellom serveren og klienten kan være hvilket som helst etter utviklerens skjønn. For meg ser JSON-formatet ut til å være det mest praktiske og visuelle, selv om en ekte applikasjon kan støtte flere formater. La oss nå fokusere på strukturen og nødvendige attributter til responsobjektet. Ja, vi vil pakke alle data som returneres av serveren i en spesiell beholder - generisk responsobjekt, som vil inneholde alt nødvendig tjenesteinformasjon for den videre behandlingen. Så, hva er denne informasjonen:

Suksess - markør for suksessen til forespørselen

For umiddelbart å forstå når du mottar et svar fra serveren om forespørselen var vellykket og for å sende den til den riktige behandleren, er det nok å bruke suksesstokenet "suksess". Det enkleste serversvaret, som ikke inneholder data, vil se slik ut:

POST /api/v1/articles/22/publish ("suksess": sant)

Feil - feildetaljer

Hvis forespørselen mislykkes - vi snakker om årsakene og typene av negative serversvar litt senere - legges attributtet "feil" til svaret, som inneholder HTTP-statuskoden og teksten til feilmeldingen. Vennligst ikke forveksle med meldinger om valideringsfeil data for spesifikke felt. Det er mest riktig, etter min mening, å returnere statuskoden i svarhodet, men jeg har også sett en annen tilnærming - returner alltid status 200 (suksess) i overskriften, og send detaljer og mulige feildata i kroppen til respons.

GET /api/v1/user ("suksess": usann, "feil": ("kode": 401, "melding": "Autorisasjon mislyktes"))

Data - data returnert av serveren

De fleste serversvar er designet for å returnere data. Avhengig av typen forespørsel og suksess, vil det forventede datasettet variere, men "data"-attributtet vil være tilstede i de aller fleste svar.

Eksempel på data returnert hvis vellykket. I dette tilfellet inneholder svaret det forespurte brukerobjektet.

GET /api/v1/bruker ("suksess": sant, "data": ( "id": 125, "e-post": " [e-postbeskyttet]", "name" : "John", "surname" : "Smith", ) )

Et eksempel på dataene som returneres i tilfelle feil. I dette tilfellet inneholder den feltnavn og valideringsfeilmeldinger.

PUT /api/v1/user ( "success": false, "error": ( "code" : 422, "message" : "Validering mislyktes") "data": ( "email" : "E-posten kunne ikke være tom. ", ))

Paginering - informasjon nødvendig for å organisere sidenavigering

I tillegg til selve dataene, i svar som kommer tilbake sett med samlingselementer, informasjon om sidenavigering (paginering) basert på søkeresultatene må være tilstede.

Minimumssettet med verdier for paginering består av:

• totalt antall poster;
• Antall sider;
• gjeldende sidetall;
• antall poster per side;
• maksimalt antall poster per side som støttes av serversiden.

Noen webutviklere API-ene inkluderer også i pagineringen et sett med ferdige lenker til tilstøtende sider, samt den første, siste og nåværende.

GET /api/v1/articles Svar: ( "success": true, "data": [ ( "id" : 1, "title" : "Interessant ting", ), ( "id" : 2, "title" : "Kjedelig tekst", ) ], "paginering": ( "totalRecords" : 2, "totalPages" : 1, "currentPage" : 1, "perPage" : 20, "maxPerPage" : 100, ) )

Arbeid med feil

Som nevnt ovenfor er ikke alle forespørsler til web-API-en vellykket, men dette er også en del av spillet. Feilrapporteringssystemet er kraftig verktøy, lette klientens arbeid og veilede klientsøknaden på rett vei. Ordet «feil» i denne sammenheng er ikke helt passende. Et bedre ord her ville vært unntak, siden forespørselen faktisk ble mottatt, analysert, og et tilstrekkelig svar ble returnert som forklarer hvorfor forespørselen ikke kunne fullføres.

Hva er de potensielle årsakene til unntakene du mottar?

500 Intern serverfeil - alt er ødelagt, men vi fikser det snart

Dette er akkurat tilfellet når problemet oppsto på siden av selve serveren, og klientapplikasjonen kan bare sukke og varsle brukeren om at serveren er sliten og legger seg ned for å hvile. For eksempel er forbindelsen til databasen tapt eller det er en feil i koden.

400 Dårlig forespørsel - og nå er alt ødelagt for deg

Svaret er nøyaktig det motsatte av det forrige. Returneres i tilfeller hvor klientapplikasjonen sender en forespørsel som i prinsippet ikke kan behandles riktig, ikke inneholder nødvendige parametere eller har syntaksfeil. Dette kan vanligvis løses ved å lese web-API-dokumentasjonen på nytt.

401 Uautorisert - fremmed, identifiser deg

Det kreves autorisasjon for å få tilgang til denne ressursen. Å ha autorisasjon garanterer selvfølgelig ikke at ressursen blir tilgjengelig, men uten autorisasjon vil du definitivt ikke vite det. Oppstår for eksempel når du prøver å få tilgang til en privat del av API eller når gjeldende token har utløpt.

403 Forbudt - du har ikke lov her

Den forespurte ressursen finnes, men brukeren har ikke tilstrekkelige rettigheter til å se eller endre den.

404 Ikke funnet - ingen bor på denne adressen

Et slikt svar returneres som regel i tre tilfeller: banen til ressursen er feil (feil), den forespurte ressursen ble slettet og sluttet å eksistere, rettighetene til den nåværende brukeren tillater ham ikke å vite om eksistensen av den forespurte ressursen. For eksempel, mens vi så gjennom en liste over produkter, gikk en av dem plutselig ut av stilen og ble fjernet.

405 Metode ikke tillatt - du kan ikke gjøre dette

Denne typen unntak er direkte relatert til verbet som brukes i forespørselen (GET, PUT, POST, DELETE), som igjen indikerer handlingen vi prøver å utføre med ressursen. Hvis den forespurte ressursen ikke støtter den angitte handlingen, sier serveren det eksplisitt.

422 Ubehandlebar enhet - rett og send på nytt

Et av de mest nyttige unntakene. Returneres når det er logiske feil i forespørselsdataene. Med forespørselsdata mener vi enten et sett med parametere og deres tilsvarende verdier som sendes av GET-metoden, eller felter til et objekt som sendes i forespørselens kropp POST metoder, PUT og SLETT. Hvis dataene ikke er validert, returnerer serveren en rapport i "data"-delen om hvilke parametere som er ugyldige og hvorfor.

HTTP-protokollen støtter mye større antall ulike statuskoder for alle anledninger, men i praksis brukes de sjelden og er i sammenheng med web-API til ingen praktisk nytte. I mitt minne har jeg aldri måttet gå lenger enn listen over unntak.

Forespørsler

Henter samlingsobjekter

En av de vanligste forespørslene er anmodningen om å få innsamlingselementer. Klientapplikasjonen viser informasjonsfeeder, produktlister, diverse informasjon og statistiske tabeller og mye mer ved å få tilgang til innsamlingsressurser. For å gjøre denne forespørselen får vi tilgang til samlingen ved å bruke GET-metoden og sender ytterligere parametere i spørringsstrengen. Som vi allerede har indikert ovenfor, forventer vi som svar å motta en rekke homogene samlingselementer og informasjonen som er nødvendig for paginering - laster fortsettelsen av listen eller dens spesifikke side. Innholdet i utvalget kan spesielt begrenses og sorteres ved hjelp av overføringen tilleggsparametere. De vil bli diskutert videre.

Sidenavigering

side- parameteren angir hvilken side som skal vises. Hvis denne parameteren ikke passeres, vises den første siden. Fra det første vellykkede svaret fra serveren vil det være klart hvor mange sider samlingen har med gjeldende filtreringsparametere. Hvis verdien overskrider maksimalt antall sider, er det best å returnere en feil 404 ikke funnet.

FÅ /api/v1/news?page=1

per side- indikerer ønsket antall elementer på siden. Vanligvis har API egenverdi som standard, som returnerer perPage som et felt i pagineringsdelen, men i noen tilfeller lar deg øke denne verdien til rimelige grenser ved å gi maksimal verdi maxPerPage:

FÅ /api/v1/news?perPage=100

Sortering av resultater

Ofte vil du sortere resultatene av et utvalg ved stigende eller synkende verdier for visse felt som støtter komparativ (for numeriske felt) eller alfabetisk (for strengfelt) sortering. For eksempel må vi organisere en liste over brukere etter navn eller produkter etter pris. I tillegg kan vi sette sorteringsretningen fra A til Å eller i motsatt retning, og den er forskjellig for ulike felt.

Sorter etter- Det er flere tilnærminger til å overføre komplekse sorteringsdata i GET-parametere. Her er det nødvendig å tydelig angi sorteringsrekkefølge og retning.

Noen APIer foreslår å gjøre dette som en streng:

GET /api/v1/products?sortBy=name.desc,price.asc

Andre alternativer foreslår å bruke en matrise:

FÅ /api/v1/produkter? sortBy=navn& sortBy=desc& sortBy=pris& sortBy=asc

Generelt er begge alternativene like, siden de formidler de samme instruksjonene. Etter min mening er alternativet med en matrise mer universelt, men som de sier, det avhenger av smak og farge ...

Enkel filtrering etter verdi

For å filtrere et utvalg etter verdien til et felt, er det i de fleste tilfeller nok å sende feltnavnet og den nødvendige verdien som en filterparameter. For eksempel ønsker vi å filtrere artikler etter forfatter-ID:

GET /api/v1/articles?authorId=25

Avanserte filtreringsalternativer

Mange grensesnitt krever mer komplekse filtrerings- og søkesystemer. Jeg vil liste opp de viktigste og vanligste filtreringsalternativene.

Filtrering etter øvre og nedre grenser ved å bruke sammenligningsoperatorer fra (større enn eller lik), høyere (større enn), til (mindre enn eller lik), lavere (mindre enn). Gjelder felt der verdiene kan rangeres.

FÅ /api/v1/products?price=500&price=1000

Filtrer etter flere mulige verdier fra listen. Gjelder felt hvis sett med mulige verdier er begrenset, for eksempel et filter med flere statuser:

FÅ /api/v1/products?status=1&status=2

Filtrering etter delvis strengmatch. Gjelder felt som inneholder tekstdata eller data som kan sidestilles med tekst, for eksempel numeriske produkt-SKUer, telefonnumre osv.

GET /api/v1/users?name=John GET /api/v1/products?code=123

Navngitte filtre

I noen tilfeller, når visse sett med filterparametere ofte brukes og antydes av systemet som noe holistisk, spesielt hvis de påvirker den interne, ofte komplekse mekanikken til prøvetaking, er det tilrådelig å gruppere dem i såkalte navngitte filtre. Det er nok å sende filternavnet i forespørselen, og systemet vil bygge utvalget automatisk.

GET /api/v1/products?filters=anbefalt

Navngitte filtre kan også ha sine egne parametere.

FÅ /api/v1/products?filters=kidds

I denne underdelen prøvde jeg å snakke om de mest populære alternativene og metodene for å få den nødvendige prøven. Mest sannsynlig vil det i din praksis være mange flere eksempler og nyanser angående dette emnet. Hvis du har noe å legge til i materialet mitt, blir jeg bare glad. I mellomtiden har innlegget allerede vokst til en betydelig skala, så vi vil analysere andre typer forespørsler i neste tilnærming.

Begrepet "klient-server" kan beskrive Maskinvare og betyr i dette tilfellet nettverksbaserte server- og klientdatamaskiner eller en måte å organisere programvare og tjenester på et nettverk.

Klient-tjener-modell (klient/server) – en databehandlingsmodell der behandlingen belastes applikasjonsprogrammer distribuert mellom en klientdatamaskin og en serverdatamaskin som deler informasjon via et nettverk. Denne modellen kombinerer fordelene med sentralisert databehandling og klientmodellen. Vanligvis er en klient sluttbrukerprogramvare som kjører på WS og er i stand til å kommunisere med en server (vanligvis en databaseserver). Ytelsen ved bruk av klient-server-modellen er høyere enn vanlig, siden klienten og serveren deler databehandlingsbelastningen. Klient-server-modellen fungerer best når du får tilgang til store datamengder.

Klient-tjener-arkitektur er en måte å organisere interaksjonen mellom programmer eller komponenter i et flerkomponentprogram på, noe som innebærer tilstedeværelsen av et program eller programkomponent kalt en server og en eller flere andre komponenter kalt klienter.

En klient er en lokal nettverkskomponent som ber om tjenester fra en server, og en server er en lokal nettverkskomponent som tilbyr tjenester til noen klienter. Den lokale nettverksserveren gir ressurser (tjenester) til arbeidsstasjoner og/eller andre servere. I et klient-serversystem sender klienten en forespørsel til serveren, og all informasjonsbehandling skjer på serveren.

Kjernen i klient/server-arkitekturen er databaseserveren (et system som mottar forespørsler fra klientprogrammer over et datanettverk og svarer med de forespurte dataene (et sett med svar); hver databaseserver består av en datamaskin, operativsystem og DBMS-serverprogramvare), som er en applikasjon som utfører et sett med databehandlingshandlinger: utføre spørringer, lagre og sikkerhetskopiere data, spore referanseintegritet, sjekke brukerrettigheter og privilegier og vedlikeholde en transaksjonslogg. Vanligvis sender klienter over et datanettverk forespørsler til serveren i form av setninger i SQL-språk. Serveren tolker dem og sender tilsvarende data tilbake til klienten.

Klienten har muligheten til å starte utføringen av serverprosedyrer asynkront for serveren og motta resultatene av deres utførelse. Vanligvis lar en klient-tjener-arkitektur flere klienter samhandle med en server parallelt og uavhengig av hverandre.

I sin enkleste form består klient-server-arkitektur av tre hovedkomponenter:

En databaseserver som administrerer datalagring, tilgang og sikkerhet, sikkerhetskopier, overvåker dataintegritet i henhold til forretningsregler og, viktigst av alt, oppfyller klientforespørsler;

En klient som gir et brukergrensesnitt, utfører applikasjonslogikk, validerer data, sender forespørsler til serveren og mottar svar fra den;

Nettverks- og kommunikasjonsprogramvare som kommuniserer mellom klient og server ved hjelp av nettverksprotokoller.

DB, om strukturell Språk SQL-spørringer (Structured Query Language), som er industristandard i en verden av relasjonsdatabaser. Ekstern server godtar forespørselen og videresender den til SQL-databasetjeneren. SQL server – spesialprogram, som administrerer den eksterne databasen. SQL-serveren gir tolkning av forespørselen, dens utførelse i databasen, generering av resultatet av forespørselen og levering av den til klientapplikasjonen. I dette tilfellet er ikke ressursene til klientdatamaskinen involvert i den fysiske utførelsen av forespørselen; klientdatamaskinen sender kun en forespørsel til serverdatabasen og mottar resultatet, hvoretter den tolker det som nødvendig og presenterer det for brukeren. Siden resultatet av forespørselen sendes til klientapplikasjonen, "reiser" bare dataene som klienten trenger gjennom nettverket. Som et resultat reduseres belastningen på nettverket. Siden forespørselen utføres der dataene er lagret (serveren), er det ikke nødvendig å sende store mengder data. I tillegg optimaliserer SQL-serveren, hvis mulig, den mottatte spørringen slik at den utføres på minimum tid med minst mulig overhead [[3.2], [3.3]]. systemet er vist i fig. 3.3.

Alt dette øker systemytelsen og reduserer tiden det tar å vente på et forespørselsresultat. Når spørringer utføres av serveren, økes graden av datasikkerhet betydelig, siden dataintegritetsregler er definert i databasen på serveren og er de samme for alle applikasjoner som bruker denne databasen. Dette eliminerer muligheten for å definere motstridende regler for å opprettholde integritet. Den kraftige transaksjonsmotoren som støttes av SQL-servere gjør det mulig å forhindre samtidige endringer av samme data av forskjellige brukere og gir muligheten til å rulle tilbake til de opprinnelige verdiene når du gjør endringer i databasen som endte unormalt [[3.2], [ 3.3]].

Ris. 3.3. Klient-server-arkitektur

• Det er et lokalt nettverk bestående av klientdatamaskiner, som hver har en klientapplikasjon installert for arbeid med databasen.
• På hver av klientdatamaskinene har brukerne muligheten til å kjøre applikasjonen. Ved å bruke brukergrensesnittet fra applikasjonen, starter den et anrop til DBMS som ligger på serveren for å hente/oppdatere informasjon. For kommunikasjon brukes et spesielt spørrespråk SQL, dvs. Bare forespørselsteksten overføres over nettverket fra klienten til serveren.
• DBMS initierer anrop til data som ligger på serveren, som et resultat av at all databehandling utføres på serveren og kun resultatet av forespørselen kopieres til klientdatamaskinen. Dermed returnerer DBMS resultatet til applikasjonen.

La oss se på hvordan separasjonen av funksjoner mellom serveren og klienten ser ut.

• Klientapplikasjonsfunksjoner:
  • Sender forespørsler til serveren.
  • Tolkning av søkeresultater mottatt fra serveren.
  • Presentere resultatene for brukeren i en eller annen form (brukergrensesnitt).
• Funksjoner på serversiden:
  • Motta forespørsler fra klientapplikasjoner.
  • Tolking av forespørsler.
  • Optimalisering og utførelse av databasespørringer.
  • Sender resultater til klientapplikasjonen.
  • Sikre et sikkerhetssystem og tilgangskontroll.
  • Databaseintegritetsstyring.
  • Implementering av stabilitet av flerbrukerdriftsmodus.

Såkalte "industrielle" DBMS-er opererer i klient-server-arkitekturen. De kalles industrielle fordi det er DBMS i denne klassen som kan gi arbeidet informasjonssystemer omfanget av en mellomstor og stor bedrift, organisasjon, bank. Kategorien industriell DBMS inkluderer MS SQL Server, Oracle, Gupta, Informix, Sybase, DB2, InterBase og en rekke andre [[3.2]].

Som regel vedlikeholdes en SQL-server av en enkelt ansatt eller en gruppe ansatte (SQL-serveradministratorer). De administrerer de fysiske egenskapene til databaser, utfører optimalisering, konfigurasjon og omdefinering ulike komponenter databaser, opprette nye databaser, endre eksisterende osv., og også utstede privilegier (tillatelser til et visst nivå av tilgang til spesifikke databaser, SQL-server) til ulike brukere [[3.2]].

La oss se på hovedfordelene med denne arkitekturen sammenlignet med filserverarkitekturen:

• Nettverkstrafikken er betydelig redusert.
• Kompleksiteten til klientapplikasjoner reduseres (mesteparten av belastningen faller på serverdelen), og følgelig reduseres kravene til maskinvarekapasiteten til klientdatamaskiner.
• Tilgjengelighet av spesielle programvareverktøy– SQL server – fører til at en betydelig del av design- og programmeringsoppgavene allerede er løst.
• Integriteten og sikkerheten til databasen er betydelig økt.

Ulemper inkluderer høyere Finansielle utgifter for maskinvare og programvare, og også det faktum at et stort antall klientdatamaskiner plassert på forskjellige steder forårsaker visse vanskeligheter med rettidig oppdatering klientapplikasjoner på alle klientdatamaskiner. Imidlertid har klient-server-arkitekturen vist seg i praksis, i for tiden Det er et stort antall databaser bygget i samsvar med denne arkitekturen.

3.4. Tre-lags (flerlags) klient-tjener-arkitektur.

Tre-link (i noen tilfeller multi-link) arkitektur(N-tier eller multi- tre-lags arkitektur? Nå, når forretningslogikken endres, er det ikke lenger behov for å endre klientapplikasjoner og oppdatere dem for alle brukere. I tillegg reduseres kravene til brukerutstyr mest mulig.

Så, som et resultat, er arbeidet strukturert som følger:

• Databasen i form av et sett med filer ligger på harddisken til en spesielt dedikert datamaskin (nettverksserver).
• DBMS er også plassert på nettverksserveren.
• Det er en spesielt dedikert applikasjonsserver som forretningsanalyseprogramvaren (forretningslogikk) er plassert på [[3.1]].
• Det er mange klientdatamaskiner, som hver har en såkalt "tynn klient" installert - en klientapplikasjon som implementerer brukergrensesnittet.
• På hver av klientdatamaskinene har brukerne mulighet til å kjøre en applikasjon – en tynnklient. Ved å bruke brukergrensesnittet fra applikasjonen, starter den et anrop til Business Intelligence-programvaren som ligger på applikasjonsserveren.
• Applikasjonsserveren analyserer brukerkrav og genererer spørringer til databasen. For kommunikasjon brukes et spesielt spørrespråk SQL, dvs. Bare forespørselsteksten overføres over nettverket fra applikasjonsserveren til databaseserveren.
• DBMS kapsler inn i seg all informasjon om den fysiske strukturen til databasen som ligger på serveren.
• DBMS initierer anrop til data som ligger på serveren, som et resultat av at resultatet av spørringen blir kopiert til applikasjonsserveren.
• Applikasjonsserveren returnerer resultatet til klientapplikasjonen (brukeren).
• Applikasjonen, ved hjelp av brukergrensesnittet, viser resultatet av spørringene.