Uanset hvordan begrebet klient-server-arkitektur er defineret (og der er mange sådanne definitioner i litteraturen), er grundlaget for dette koncept en distribueret computermodel. I det mest generelle tilfælde, under klient Og server to interagerende processer forstås, hvoraf den ene er en udbyder af en eller anden service til den anden.

Udtrykket "klient-server" betyder en arkitektur af en softwarepakke, hvor dens funktionelle dele interagerer i henhold til "request-response"-skemaet. Hvis vi betragter to interagerende dele af dette kompleks, så udfører den ene af dem (klienten) en aktiv funktion, det vil sige, den initierer anmodninger, og den anden (serveren) reagerer passivt på dem. Efterhånden som systemet udvikler sig, kan rollerne ændre sig, f.eks. vil en eller anden softwareblok samtidigt udføre en servers funktioner i forhold til en blok og en klient i forhold til en anden.

Server - en eller flere flerbrugerprocessorer med et enkelt hukommelsesfelt, som i overensstemmelse med brugerens behov giver dem funktionerne beregning, kommunikation og adgang til databaser. Server kan kaldes et program, der leverer nogle tjenester til andre programmer. Eksempler på servere er Apache-webserveren, databaseservere - MySQL, ORACLE, netværksfilsystemer og Windows-printere.

Kunde - arbejdsstation for én bruger, at levere registreringstilstanden og andre funktioner, der er nødvendige på hans arbejdsplads - beregninger, kommunikation, adgang til databaser osv. En klient kan kaldes et program, der bruger den service, som serverprogrammet leverer. Klienteksempler - MSIE (MS Internet Explorer), ICQ-klient.

Ofte henviser folk blot til den computer, hvor et af disse programmer kører, som en klient eller server.

I det væsentlige er klient og server roller, eksekverbare programmer. Klienter og servere kan fysisk opholde sig på den samme computer. Det samme program kan være både en klient og en server på samme tid osv... det er bare roller.

Hvis vi tegner en analogi med samfundet - en bank eller en butik - "servere". De leverer nogle tjenester til deres kunder. Men banken kan samtidig være kunde i en anden virksomhed osv...

Klient-server-behandling er et miljø, hvor applikationsbehandling er fordelt mellem en klient og en server. Maskiner er ofte involveret i forarbejdning forskellige typer, og klienten og serveren kommunikerer med hinanden ved hjælp af et fast sæt standardudvekslingsprotokoller og -procedurer til at få adgang til fjernplatforme.

DBMS med personlige computere(såsom Clipper, DBase, FoxPro, Paradox, Clarion har netværksversioner, der blot deler databasefiler i de samme formater til pc'en, mens de implementerer netværkslåse for at begrænse adgangen til tabeller og poster. I dette tilfælde udføres alt arbejde på PC'en. Serveren bruges blot som en delt fjerndisk stor kapacitet. Denne måde at arbejde på medfører risiko for datatab på grund af hardwarefejl.

Sammenlignet med sådanne systemer har systemer bygget i Client-Server-arkitekturen følgende fordele:

giver dig mulighed for at øge størrelsen og kompleksiteten af ​​programmer, der kører på en arbejdsstation;


sikrer overførsel af de mest arbejdskrævende operationer til en server, som er en maskine med større computerkraft;


minimerer muligheden for tab af information indeholdt i databasen gennem brug af interne databeskyttelsesmekanismer, der er tilgængelige på serveren, såsom f.eks. transaktionssporingssystemer, rollback efter en fejl og midler til at sikre dataintegritet;


reducerer mængden af ​​information, der transmitteres over netværket flere gange.


I en klient-server-arkitektur giver databaseserveren ikke kun adgang til delte data, men håndterer også al behandling af disse data. Klienten sender anmodninger til serveren om at læse eller ændre data, som er formuleret i SQL. Serveren selv foretager alle de nødvendige ændringer eller valg, mens den overvåger integriteten og konsistensen af ​​dataene, og sender resultaterne i form af et sæt poster eller en returkode til klientens computer.


Det giver dig mulighed for optimalt at fordele computerbelastningen mellem klienten og serveren, hvilket også påvirker mange af systemets egenskaber: omkostninger, ydeevne, support.


1.2. Historie…


Arkitekturen og udtrykket "klient-server" blev først brugt i begyndelsen af ​​80'erne. De første applikationer med en klient-server-arkitektur var databaser.


Før dette var der ingen klar opdeling – programmet klarede som regel alt selv – herunder arbejde med data i filsystem, præsentation af data til brugeren osv. Med tiden voksede mængden og kritikaliteten af ​​data for erhvervslivet, og dette begyndte med tiden at give anledning til problemer (performance, sikkerhed og andre).


Så fandt de ud af, at det ville være praktisk at installere databasen på en kraftfuld separat computer(server) og tillade denne database at blive brugt af mange små computerbrugere (klienter) over netværket, hvilket blev gjort.


Grundlæggende var "eksplosionen" i klient-serverteknologiens popularitet forårsaget af IBMs opfindelse af et simpelt forespørgselssprog relationelle databaser SQL data. I dag er SQL den universelle standard for at arbejde med databaser. For nylig fortsætter denne "eksplosion" med opfindelsen af ​​internettet, hvor bogstaveligt talt enhver interaktion finder sted ved hjælp af en klient-server-arkitektur.


1.3. Protokoller


Serveren og klienten på netværket "taler" med hinanden på et "sprog" (i ordets brede betydning), der er forståeligt for begge parter. Dette "sprog" kaldes en protokol.


I tilfælde af en bank kan protokollen kaldes de formularer, som klienten udfylder.


I vores tilfælde, eksempler på protokoller:


FTP ( Filoverførsel protokol)


HTTP (Hyper Text Transfer Protocol)


SMTP (Simple Mail Transfer Protocol)


IP (internetprotokol)


MySQL Client/Server Protocol


Bemærk, at protokoller kan være forskellige niveauer. Klassifikationssystemer for niveauer kan være forskellige, men en af ​​de mest berømte linjer er OSI (Open Systems Interconnection), som har 7 niveauer.


For eksempel er HTTP en applikationsprotokol (syvende - højeste) lagprotokol, og IP er en netværksprotokol (tredje) lag.


1.4. Fordeling af funktioner i klient-server-arkitekturen


I klassisk arkitektur Klient-serveren skal distribuere de tre hoveddele af applikationen på tværs af to fysiske moduler. Typisk er datalagringssoftware placeret på en server (for eksempel en databaseserver), brugergrænsefladen er på klientsiden, men databehandlingen skal fordeles mellem klient- og serverdelen. Dette er den største ulempe ved den to-lags arkitektur, hvorfra flere ubehagelige træk, hvilket i høj grad komplicerer udviklingen af ​​klient-server-systemer.


Udviklingsprocessen af ​​sådanne systemer er ret kompleks, og en af ​​de vigtigste opgaver er beslutningen om, hvordan applikationens funktionalitet skal fordeles mellem klient- og serverdelene. I et forsøg på at løse dette problem får udviklere to-lags, tre-tier og multi-tier arkitekturer. Det hele afhænger af, hvor mange mellemled der er inkluderet mellem klienten og serveren.


Hovedproblemet, som det løser klientapplikation, giver en grænseflade med brugeren, dvs. indtastning af data og præsentation af resultater i en brugervenlig form, og styring af applikationsscenarier.


Hovedfunktionerne i en server-DBMS er at sikre pålidelighed, konsistens og sikkerhed af data, håndtering af klientanmodninger og hurtig behandling af SQL-forespørgsler.


Hele applikationens logik - applikationsopgaver, forretningsregler - i en tolagsarkitektur fordeles af udvikleren mellem to processer: klient og server (fig. 1).


Først blev de fleste af applikationens funktioner løst af klienten, serveren var kun involveret i at behandle SQL-forespørgsler. Denne arkitektur kaldes "tyk klient - tynd server".


Fremkomsten af ​​muligheden for at oprette lagrede procedurer på serveren, det vil sige kompilerede programmer med intern driftslogik, har ført til en tendens til at overføre en stigende del af funktionerne til serveren. Serveren blev mere og mere "fed", og klienten blev "tyndere".


Denne løsning har åbenlyse fordele, for eksempel er det nemmere at vedligeholde, fordi alle ændringer kun skal foretages ét sted - på serveren.


De ovenfor diskuterede modeller har følgende ulemper.


1. "Tyk" klient:


– kompleksiteten af ​​administrationen;


– opdatering af softwaren bliver mere kompliceret, da den skal udskiftes samtidigt på tværs af hele systemet;


– fordelingen af ​​beføjelser bliver mere kompliceret, da adgangen ikke er begrænset af handlinger, men af ​​tabeller;


– netværket er overbelastet på grund af overførsel af ubehandlede data gennem det;


– svag databeskyttelse, da det er vanskeligt at fordele beføjelser korrekt.


2. "Fedt" server:


– implementering bliver mere kompliceret, da sprog som PL/SQL ikke er egnede til at udvikle sådan software, og der er ingen gode midler debugging;


– ydelsen af ​​programmer skrevet på sprog som PL/SQL er væsentligt lavere end dem, der er oprettet på andre sprog, hvilket har vigtig til komplekse systemer;


- programmer skrevet på DBMS-sprog fungerer normalt ikke pålideligt; en fejl i dem kan føre til fejl på hele databaseserveren;


– de resulterende programmer er fuldstændig uoverførbare til andre systemer og platforme.


For at løse disse problemer bruges klient-serverarkitekturer på flere niveauer (tre eller flere niveauer). lagdelt arkitektur klient-server giver dig mulighed for betydeligt at forenkle distribueret databehandling, hvilket gør den ikke kun mere pålidelig, men også mere tilgængelig.


Det sprog, som lagrede procedurer er skrevet på, er imidlertid ikke stærkt eller fleksibelt nok til nemt at implementere kompleks applikationslogik.


Så var der en tendens til at overlade udførelsen af ​​applikationsopgaver og forretningsregler til en separat applikationskomponent (eller flere komponenter), som kan køre enten på en specielt dedikeret computer - applikationsserveren, eller på den samme computer, hvor databaseserveren kører. . Sådan opstod tre-lags og multi-tier klient-server-arkitekturer.





Ris. 1. Fordeling af funktioner mellem klient og server


Der var en speciel software Middleware (software), der skal tillade, at flere komponenter i en sådan multi-komponent applikation kan fungere sammen. Sådanne applikationer er fleksible, skalerbare, men vanskelige at udvikle.



BIBLIOGRAFI

1. Informatik / Red. N.V. Makarova. – M.: Finans og statistik, 1998.
   

   Evdokimov V.V. Økonomisk informatik. St. Petersborg: Peter, 2004.
   

   Kazakov S.I. Grundlæggende netværksteknologier– M.: Radio og kommunikation, 2004.
   

   Kogalovsky M.R., Databaseteknologi på personlige computere, - M.: Finans og statistik, 2003.
   

   Popov V.V. Grundlæggende om computerteknologi. –M.: Finans og statistik, 2001.
   

   Figurnov V.E. IBM PC til brugeren. M., 2000.
   

OPERATIVSYSTEM MS-DOS. GRUNDLÆGGENDE KONCEPT OG KOMMANDOER GRUNDLÆGGENDE KONCEPT: DATABASE, DBMS, ENTITET, ATRIBUTE, RELATION (EN-TIL-EN, EN-TIL-MANGE, MANGE-TIL-MANGE), RELATION, PRIMÆR NØGLE

DB'er, der bruger FILSERVER-teknologi;

DB'er, der bruger CLIENT-SERVER-teknologi.

Filserver

- Adgang til databasen (forespørgsel)
- Overførsel af data, mens du blokerer adgangen til andre brugere
- Databehandling på brugerens computer

For klarhedens skyld, lad os overveje konkrete eksempler. Lad os sige, at du skal se sendte betalingsordrer for perioden fra 19. maj til 25. maj i mængden af ​​5.000 rubler. Brugeren skal starte en klientapplikation på sin computer, der fungerer i databasen med betalingsordrer, og indtaste de nødvendige udvælgelseskriterier. Hvorefter det vil blive downloadet til din computer fra databaseserveren og indlæst i vædder en fil indeholdende alle dokumenter af denne type for hele perioden for eventuelle beløb. En klientapplikation, der kører på brugerens computer, der arbejder med databasen, vil behandle disse oplysninger (sortere dem) og derefter give et svar (en liste over betalingsordrer, der opfylder dine kriterier, vises på skærmen). Herefter vil du vælge den ønskede betalingsordre og forsøge at redigere (ændre) ét felt i den - for eksempel datoen. Under redigering blokeres datakilden, det vil sige hele filen, der indeholder dette dokument. Det betyder, at filen enten slet ikke vil være tilgængelig for andre brugere, eller kun vil være tilgængelig i visningstilstand. Desuden forekommer denne form for optagelse ikke engang på rekordniveau, det vil sige ét dokument, men hele filen er låst - det vil sige hele tabellen, der indeholder lignende dokumenter. Først efter at dette felt er færdigbehandlet, og redigeringstilstanden er afsluttet, vil denne betalingsordrefil blive låst op fra at blive fanget af brugeren. Hvis dataene er gemt i større objekter, f.eks. indeholder én fil betalingsordrer for både modtagelse af midler og afsendelse af midler, så vil endnu flere af oplysningerne ikke være tilgængelige. Du vil arbejde med ét "dato"-felt i ét dokument - resten af ​​virksomhedens medarbejdere venter, indtil du er færdig.

Ulemperne ved FILSERVER-systemet er indlysende:

Meget kæmpe pres på netværket, øgede krav til båndbredde. I praksis gør det det næsten umuligt at arbejde samtidigt stort antal brugere med store mængder data.

Databehandling udføres på brugernes computer. Dette medfører øgede hardwarekrav for hver bruger. Jo flere brugere, jo flere penge skal bruges på at udstyre deres computere.

Låsning af data ved redigering af én bruger gør det umuligt for andre brugere at arbejde med disse data.

Sikkerhed. For at kunne arbejde med et sådant system, skal du give hver bruger fuld adgang til hele filen, hvor han måske kun er interesseret i ét felt.

Klient-server

Behandling af en enkelt brugeranmodning:
- Adgang til databasen (SQL-forespørgsel)
- Transmission af svaret - resultatet af behandlingen




Hvis det er nødvendigt at behandle oplysninger, der er lagret i databasen, genererer en klientapplikation, der kører på brugerens computer, der arbejder med databasen, en forespørgsel i SQL-sproget (navn fra begyndelsesbogstaverne - Structured Query Language). Databaseserveren accepterer anmodningen og behandler den uafhængigt. Ingen dataarray (fil) transmitteres over netværket. Efter behandling af anmodningen overføres kun resultatet til brugerens computer - det vil sige i det foregående eksempel en liste over betalingsordrer, der opfylder de nødvendige kriterier. Selve filen, hvori de data, der fungerede som kilde til behandling, blev gemt, forbliver ublokeret for adgang af serveren selv efter anmodning fra andre brugere.

I seriøse klient-server DBMS'er er der yderligere mekanismer, reducere belastningen på netværket, reducere kravene til brugercomputere. Som eksempel vil vi give lagrede procedurer - det vil sige hele programmer til behandling af data gemt i databasen. I dette tilfælde overføres ikke engang SQL-udtryk fra brugeren til serveren - et funktionskald med opkaldsparametre overføres. Dermed, arbejdsplads brugeroplevelsen forenkles yderligere, programmets logik overføres til serveren. Brugerrummet bliver blot et middel til at vise information. Alt dette betyder en yderligere reduktion af belastningen på netværket og brugerens arbejdsstationer.

Altså alt ovenstående ulemper FILSERVER-skemaer er elimineret i CLIENT-SERVER-arkitekturen:

Dataarrays overføres ikke over netværket fra databaseserveren til brugerens computer. Kravene til netværksbåndbredde reduceres. Dette gør det muligt for et stort antal brugere at arbejde samtidigt med store mængder data.

Databehandling udføres på databaseserveren og ikke på brugernes computer. Dette tillader brugen af ​​enklere og derfor billigere computere på klientsteder.

Data er ikke blokeret (fanget) af én bruger.

Brugeren får ikke adgang til hele filen, men kun til de data fra den, som brugeren har ret til at arbejde med.

Efter at have overvejet forskellen mellem en FILSERVER og en KLIENTSERVER, kan vi afslutte vores overvejelse af konceptet "informationslagring". Det er vigtigt at understrege, at driften af ​​virksomhedssystemet i høj grad afhænger af den anvendte type DBMS. Det er helt indlysende, at for store virksomheder, med stort beløb brugere, med kæmpe antal optegnelser i databasen, er filserverordningen fuldstændig uacceptabel. På den anden side er der forskelle i databaser i andre parametre og muligheder:

typer af data, der kan gemmes i databasen (tal, datoer, tekst, billeder, video, lyd osv.);

om teknologier organiseret af databasen selv for at få adgang til data i databasen og niveauet af informationsbeskyttelse mod uautoriseret adgang;

på de medfølgende udviklingsværktøjer og -metoder, der kan bruges til at designe ethvert informationssystem baseret på denne database;

om de leverede værktøjer og metoder til at analysere information (data), som kan anvendes i et informationssystem baseret på denne database;

i forhold til pålidelighed og stabilitet, det vil sige (omtrent) antallet af poster (udfyldte felter) i databasen, hvilket sikrer en pålidelig og uafbrudt mulighed for at få adgang til, ændre og analysere information i databasen;

efter hastighed - tid brugt på at få adgang til og behandle information;

hvis det er muligt, organiser arbejdet på computere forskellige producenter, det vil sige kompatibilitet med andre platforme og operativsystemer;

efter niveauet af support (service) leveret af databaseudvikleren eller dennes autoriserede forhandler;

på tilgængeligheden af ​​gode værktøjer til at skabe applikationer, der bruger denne database data osv.

Hvorfor er det ikke rentabelt at investere i en filserverløsning i dag? I dag er den fremtidige vej for databaseudvikling allerede indlysende. Multi-level klient-server-systemer dukker op, med meget tynde klienter, der fjerner enhver begrænsning fra klientstationer, både med hensyn til ydeevne og platform og operativsystem. Hvis for en klient-server løsning videre udvikling virker fuldstændig overskuelig, og overgangen fra en klient-server til en multi-level klient-server er ikke problematisk, så for en filserver repræsenterer en simpel overgang til en klient-server et kæmpe problem og enorme arbejdsomkostninger, hvis dette pludselig vender ude at være muligt overhovedet.

Vladimir, webudvikler hos Noveo, siger:

De fleste udviklere af websteder, webtjenester og mobilapplikationer skal før eller siden beskæftige sig med klient-server-arkitektur, nemlig at udvikle en web-API eller integrere med den. For ikke at opfinde noget nyt hver gang, er det vigtigt at udvikle en relativt universel tilgang til web-API-design, baseret på erfaringerne med at udvikle lignende systemer. Vi gør dig opmærksom på en kombineret serie af artikler om dette emne.

Tilnærmelse et: Karakterer

På et tidspunkt, i færd med at skabe endnu en webservice, besluttede jeg at samle al min viden og mine tanker om emnet design af en web-API til at opfylde behovene i klientapplikationer og sætte den i form af en artikel eller en serie af artikler. Min erfaring er selvfølgelig ikke absolut, og konstruktiv kritik og tilføjelser er mere end velkomne.

Læsningen viste sig at være mere filosofisk end teknisk, men for fans af den tekniske del vil der være noget at tænke over. Jeg tvivler på, at jeg i denne artikel vil sige noget fundamentalt nyt, noget som du aldrig har hørt om, læst eller tænkt over dig selv. Prøver bare at passe alt ind samlet system, først og fremmest i dit eget hoved, og det er allerede meget værd. Ikke desto mindre vil jeg blive glad, hvis mine tanker vil være nyttige for dig i din praksis. Så lad os gå.

Klient og server

Server i dette tilfælde betragter vi en abstrakt maskine på netværket, som er i stand til at modtage en HTTP-anmodning, behandle den og returnere det korrekte svar. I forbindelse med denne artikel er dens fysiske essens og interne arkitektur fuldstændig ligegyldig, hvad enten det er en studerende bærbar computer eller en enorm klynge af industrielle servere spredt rundt i verden. På samme måde er det lige meget for os, hvad der er under motorhjelmen, hvem der tager imod anmodningen ved døren, Apache eller Nginx, hvilket ukendt beist, PHP, Python eller Ruby behandler det og genererer et svar, hvilken datalagring der bruges : Postgresql, MySQL eller MongoDB . Det vigtigste er, at serveren opfylder hovedreglen - at høre, forstå og tilgive.

Klient det kan også være alt, der er i stand til at generere og sende en HTTP-anmodning. Indtil et vist tidspunkt i denne artikel vil vi heller ikke være særligt interesserede i de mål, som klienten sætter sig for sig selv, når han sender denne forespørgsel, eller hvad han vil gøre med svaret. Klienten kan være et JavaScript-script, der kører i browseren, mobil app, en ond (eller knap så ond) dæmon, der kører på serveren, eller et alt for klogt køleskab (der findes allerede sådanne ting).

For det meste vil vi tale om kommunikationsmetoden mellem de to ovennævnte, på en sådan måde, at de forstår hinanden, og ingen af ​​dem har nogen spørgsmål.

REST Filosofi

REST (Representational state transfer) blev oprindeligt tænkt som en enkel og utvetydig grænseflade til datahåndtering, som kun involverede nogle få grundlæggende operationer med direkte netværkslagring (server): datahentning (GET), lagring (POST), modifikation (PUT/PATCH). ) og sletning (SLET). Selvfølgelig var denne liste altid ledsaget af muligheder som behandlingsfejl i anmodningen (er anmodningen kompileret korrekt), begrænsning af adgang til data (pludselig skulle du ikke vide dette) og validering af indgående data (pludselig skrev du noget sludder), i generelt, af alle mulige kontroller, som serveren udfører, før ønsket opfyldes klient.

Derudover har REST en række arkitektoniske principper, som du kan finde en liste over i enhver anden artikel om REST. Lad os gennemgå dem kort, så de er ved hånden, og du ikke behøver at gå nogen steder:

Serverens uafhængighed af klienten- servere og klienter kan øjeblikkeligt erstattes af andre uafhængigt af hinanden, da grænsefladen mellem dem ikke ændres. Serveren gemmer ikke klienttilstande.
Unikhed af ressourceadresser- hver dataenhed (af enhver grad af indlejring) har sin egen unikke URL, som faktisk er helt en unik ressourceidentifikator.

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

Uafhængighed af datalagringsformatet fra transmissionsformatet- serveren kan understøtte flere forskellige formater til at overføre de samme data (JSON, XML osv.), men gemmer dataene i dets interne format, uanset de understøttede.

Tilstedeværelse af alle nødvendige metadata i svaret- ud over selve dataene skal serveren returnere detaljer om anmodningsbehandling, for eksempel fejlmeddelelser, forskellige ressourceegenskaber, der er nødvendige for videre arbejde med det, for eksempel, det samlede antal poster i samlingen for at vise pagineringsnavigation korrekt. Vi vil gennemgå de forskellige typer ressourcer senere.

Hvad mangler vi?

Classic REST involverer, at klienten arbejder med serveren som et fladt datalager, mens der ikke siges noget om forbindelsen og indbyrdes afhængighed af data indbyrdes. Alt dette falder som standard helt på klientapplikationens skuldre. Moderne fagområder, som datastyringssystemer er udviklet til, hvad enten det er sociale tjenester eller online markedsføringssystemer, indebærer imidlertid et komplekst forhold mellem de enheder, der er lagret i databasen. Understøttelse af disse forbindelser, dvs. dataintegritet er serversidens ansvar, mens klienten kun er en grænseflade for at få adgang til disse data. Så hvad mangler vi i REST?

Funktionsopkald

For ikke at ændre data og forbindelser mellem dem manuelt, kalder vi blot en funktion på ressourcen og "føder" de nødvendige data til den som et argument. Denne operation passer ikke til REST-standarderne, der er ikke noget særligt verbum for det, som tvinger os, udviklere, til at komme ud af vores egen måde.

Det enkleste eksempel– brugerautorisation. Vi kalder login-funktionen, giver den et objekt, der indeholder legitimationsoplysninger som et argument, og modtager en adgangsnøgle som svar. Vi er ligeglade med, hvad der sker med dataene på serversiden.

En anden mulighed– skabe og bryde forbindelser mellem data. For eksempel tilføjelse af en bruger til en gruppe. Ringer til enheden gruppe addUser-funktion, der sender et objekt som en parameter bruger, får vi resultatet.

Og også Der er operationer, der ikke er direkte relateret til lagring af data som sådan, for eksempel at sende meddelelser, bekræfte eller afvise eventuelle operationer (afslutning af rapporteringsperioden osv.).

Flere operationer

Det sker ofte, og klientudviklere vil forstå, hvad jeg mener, at det er mere bekvemt for en klientapplikation at oprette/ændre/slette/flere homogene objekter på én gang med én anmodning, og for hvert objekt er en anden serverside-afgørelse mulig. . Der er i det mindste flere muligheder her: enten er alle ændringer blevet gennemført, eller de er blevet delvist gennemført (for nogle objekter), eller der er opstået en fejl. Nå, der er også flere strategier: Anvend kun ændringer, hvis alle lykkes, eller anvend delvist, eller rul tilbage i tilfælde af fejl, og dette fører allerede til en fuldgyldig transaktionsmekanisme.

For en web-API, der stræber efter idealitet, vil jeg også gerne på en eller anden måde bringe sådanne operationer ind i systemet. Det vil jeg prøve at gøre i en af ​​efterfølgerne.

Statistiske forespørgsler, aggregatorer, dataformatering

Det sker ofte, at vi, baseret på data gemt på serveren, har brug for at få en statistisk oversigt eller data formateret på en speciel måde: for eksempel for at bygge en graf på klientsiden. I bund og grund er dette data genereret efter behov, mere eller mindre på farten, og er skrivebeskyttet, så det giver mening at indsætte det. særskilt kategori. En af Karakteristiske træk statistiske data er efter min mening, at de ikke har et unikt ID.

Jeg er sikker på, at dette ikke er alt, man kan støde på, når man udvikler rigtige applikationer, og jeg vil være glad for at se dine tilføjelser og justeringer.

Datatyper

Objekter

Nøgledatatypen i kommunikationen mellem klient og server er et objekt. Grundlæggende er et objekt en liste over egenskaber og deres tilsvarende værdier. Vi kan sende et objekt til serveren i en anmodning og modtage anmodningsresultatet som et objekt. I dette tilfælde vil objektet ikke nødvendigvis være en reel enhed gemt i databasen, men i det mindste, i den form, den blev sendt eller modtaget i. For eksempel sendes autorsom et objekt, men er ikke en uafhængig enhed. Selv objekter, der er gemt i databasen, har en tendens til at erhverve yderligere egenskaber af intra-system karakter, for eksempel datoer for oprettelse og redigering, forskellige systemetiketter og flag. Objektegenskaber kan enten være deres egne skalarværdier eller indeholde relaterede objekter Og samlinger af genstande, som ikke er en del af objektet. Nogle objektegenskaber kan redigeres, nogle er systemegenskaber, skrivebeskyttede, og nogle kan være statistiske og beregnes på farten (f.eks. antallet af likes). Nogle objektegenskaber kan være skjulte, afhængigt af brugerens rettigheder.

Samlinger af genstande

Når vi taler om samlinger, mener vi en type serverressource, der giver dig mulighed for at arbejde med en liste af homogene objekter, dvs. tilføje, slette, ændre objekter og vælge blandt dem. Derudover kunne en samling teoretisk set have sine egne egenskaber (for eksempel det maksimale antal elementer pr. side) og funktioner (jeg er forvirret her, men det skete også).

Skalære værdier

I deres rene form har skalære værdier som en separat enhed været yderst sjældne i min hukommelse. Typisk har de optrådt som egenskaber ved genstande eller samlinger, og som sådan kan de læses eller skrives. For eksempel kan brugernavnet hentes og ændres individuelt med GET /brugere/1/navn . I praksis er denne funktion sjældent brugbar, men hvis det er nødvendigt, vil jeg gerne have den lige ved hånden. Dette gælder især for samlingsegenskaber, såsom antallet af poster (med eller uden filtrering): GET /news/count .

I en af ​​de følgende artikler vil jeg forsøge at klassificere disse operationer og tilbyde muligheder mulige anmodninger og svar ud fra hvilke jeg stødte på i praksis.

Tilnærmelse to: Den rigtige vej

I denne tilgang vil jeg gerne tale separat om tilgange til at bygge unikke stier til ressourcer og metoder i din web-API og om de arkitektoniske funktioner i applikationen, der påvirker udseende denne vej og dens komponenter.

Hvad skal man tænke på, mens man står på kysten

Versionering

Før eller siden begynder ethvert operativsystem at udvikle sig: udvikle sig, blive mere komplekst, skalere og blive mere moderne. For REST API-udviklere er dette først og fremmest fyldt med behovet for at lancere nye versioner af API'et, mens de gamle kører. Her taler jeg ikke længere om arkitektoniske ændringer under motorhjelmen på dit system, men om det faktum, at selve dataformatet og operationssættet med det ændrer sig. Under alle omstændigheder skal versionering leveres som i den oprindelige organisation kildekode, og i princippet URL-konstruktion. Når det kommer til URL'er, er der to mest populære måder at angive den version af API'en, som anmodningen er rettet til. Præfiks for eksempel-api.com/v1/-stien og adskillelse af versioner på v1.example-api.com-underdomæneniveau. Du kan bruge enhver af dem, afhængigt af dine behov og krav.

Komponenternes autonomi

Web-API'en for komplekse systemer, der understøtter flere brugerroller, kræver ofte opdeling i dele, som hver især tjener sit eget udvalg af opgaver. Faktisk kan hver del være selvstændig applikation, arbejde på forskellige fysiske maskiner og platforme. I forbindelse med beskrivelsen af ​​API'et er det slet ikke vigtigt for os, hvordan serveren behandler anmodningen, og hvilke kræfter og teknologier der er involveret i dette. For klienten er API'en et indkapslet system. Forskellige dele af systemet kan dog have helt forskellig funktionalitet, for eksempel administrations- og brugerdelen. Og metoden til at arbejde med tilsyneladende de samme ressourcer kan variere betydeligt. Derfor skal sådanne dele adskilles på niveauet af admin.v1.example-api.com-domænet eller eksempel-api.com/v1/admin/-stipræfikset. Dette krav er ikke obligatorisk, og meget afhænger af systemets kompleksitet og dets formål.

Dataudvekslingsformat

Det mest bekvemme og funktionelle, efter min mening, dataudvekslingsformat er JSON, men ingen forbyder brugen af ​​XML, YAML eller noget andet format, der giver dig mulighed for at gemme serialiserede objekter uden at miste datatypen. Hvis det ønskes, kan du gøre det i API support flere input/output formater. Det er nok at bruge HTTP-anmodningshovedet til at angive det ønskede Accept-svarformat og Content-Type til at angive formatet af de data, der transmitteres i anmodningen. Til andre populær måde er at tilføje en udvidelse til ressource-URL'en, for eksempel GET /users.xml , men denne metode virker mindre fleksibel og smuk, om ikke andet fordi den gør URL'en tungere og er mere sand for GET-anmodninger end for alle mulige operationer.

Lokalisering og flersprogethed

I praksis handler API-flersprogethed oftest om at oversætte service- og fejlmeddelelser til det påkrævede sprog for direkte visning til slutbrugeren. Flersproget indhold har også sin plads, men lagring og udsendelse af indhold på forskellige sprog, efter min mening, bør differentieres mere klart, for eksempel, hvis du har den samme artikel på forskellige sprog, så er det faktisk to forskellige enheder, grupperet baseret på indholdets enhed. Forskellige metoder kan bruges til at identificere det forventede sprog. Den enkleste er standard HTTP-headeren Accept-Language. Jeg har set andre måder, såsom at tilføje en GET-parameter language="en" , ved at bruge stipræfikset example-api.com/en/ , eller endda på domænenavnsniveau en.example-api.com . Det forekommer mig, at valget af, hvordan man angiver lokaliteten, afhænger af den specifikke applikation og de opgaver, den står over for.

Intern routing

Så vi har nået rodknuden på vores API (eller en af ​​dens komponenter). Alle yderligere ruter passerer direkte inde i din serverapplikation, i henhold til det sæt af ressourcer, det understøtter.

Indsamlingsstier

For at angive stien til samlingen bruger vi blot navnet på den tilsvarende enhed, hvis dette for eksempel er en liste over brugere, vil stien være /brugere. To metoder er anvendelige til samlingen som sådan: GET (modtagelse af en begrænset liste over enheder) og POST (oprettelse af et nyt element). I anmodninger om lister kan vi bruge mange ekstra GET-parametre, der er vant til sideoutput, sortering, filtrering, søgning osv., men de skal være valgfrie, dvs. disse parametre må ikke videregives som en del af stien!

Samlingselementer

For at få adgang til et bestemt element i samlingen bruger vi det i ruten unik identifikator/brugere/25 . Dette er den unikke vej dertil. For at arbejde med et objekt er metoderne GET (opnå et objekt), PUT/PATCH (ændre) og DELETE (sletning) anvendelige.

Unikke objekter

Mange tjenester har objekter, der er unikke for den aktuelle bruger, såsom den aktuelle brugers profil /profil eller personlige indstillinger /indstillinger. Selvfølgelig er disse på den ene side elementer i en af ​​samlingerne, men de er udgangspunktet for brugen af ​​vores web-API af klientapplikationen og tillader også en meget bredere vifte af operationer på data. Samtidig er samlingen opbevaring brugerdefinerede indstillinger er muligvis slet ikke tilgængelig på grund af sikkerheds- og databeskyttelsesårsager.

Egenskaber ved genstande og samlinger

For at komme direkte til et objekts egenskaber er det nok at tilføje egenskabsnavnet til stien til objektet, f.eks. få brugernavnet /brugere/25/navn . Metoderne GET (få en værdi) og PUT/PATCH (ændring af en værdi) er anvendelige på en egenskab. SLET-metoden er ikke anvendelig pga en egenskab er en strukturel del af et objekt, som en formaliseret enhed af data.

I den foregående del talte vi om, at samlinger ligesom genstande kan have deres egne egenskaber. Min erfaring er, at den eneste egenskab, jeg har fundet nyttig, er tælleegenskaben, men din ansøgning kan være mere kompleks og specifik. Stier til samlingsegenskaber er bygget efter samme princip som deres elementers egenskaber: /users/count . For samlingsejendomme er det kun metoden GET (få en ejendom) der er anvendelig, da en samling er blot en grænseflade til at få adgang til en liste.

Samlinger af relaterede genstande

En type objektegenskab kan være relaterede objekter eller samlinger af relaterede objekter. Sådanne entiteter er som regel ikke et objekts egen ejendom, men henviser kun til dets forbindelser med andre enheder. For eksempel en liste over roller, der blev tildelt brugeren /users/25/roles. Vi vil tale detaljeret om at arbejde med indlejrede objekter og samlinger i en af ​​de følgende dele og videre på dette tidspunkt Det er nok for os, at vi har mulighed for at få direkte adgang til dem, ligesom enhver anden egenskab ved et objekt.

Funktioner af objekter og samlinger

For at bygge stien til funktionskaldsgrænsefladen for en samling eller et objekt, bruger vi samme tilgang som til at få adgang til en egenskab. For eksempel for /users/25/sendPasswordReminder-objektet eller /users/disableUnconfirmed-samlingen. Til funktionskald bruger vi altid POST-metoden. Hvorfor? Lad mig minde dig om, at der i klassisk REST ikke er noget særligt verbum til at kalde funktioner, og derfor bliver vi nødt til at bruge en af ​​de eksisterende. Efter min mening er POST-metoden bedst egnet til dette, fordi... det giver dig mulighed for at sende de nødvendige argumenter til serveren, er ikke idempotent (returnerer det samme resultat, når det åbnes flere gange), og er det mest abstrakte inden for semantik.

Jeg håber, at alt passer mere eller mindre ind i systemet :) I den næste del vil vi tale mere detaljeret om anmodninger og svar, deres formater og statuskoder.

Tilnærmelse tre: Forespørgsler og svar

I tidligere tilnærmelser talte jeg om, hvordan ideen kom til at indsamle og opsummere den eksisterende erfaring inden for web API-udvikling. I den første del forsøgte jeg at beskrive, hvilke typer ressourcer og operationer på dem, vi beskæftiger os med, når vi designer en web-API. Den anden del berørte spørgsmålene om at konstruere unikke URL'er til at få adgang til disse ressourcer. Og i denne tilnærmelse vil jeg forsøge at beskrive de mulige muligheder for anmodninger og svar.

Universelt svar

Vi har allerede sagt, at det specifikke format for kommunikation mellem serveren og klienten kan være et hvilket som helst efter udviklerens skøn. For mig ser JSON-formatet ud til at være det mest bekvemme og visuelle, selvom et rigtigt program kan understøtte flere formater. Lad os nu fokusere på strukturen og de nødvendige attributter for svarobjektet. Ja, vi pakker alle data, der returneres af serveren, i en speciel beholder - generisk svarobjekt, som vil indeholde alt det nødvendige serviceoplysninger for dens videre behandling. Så hvad er denne information:

Succes - markør for succesen af ​​anmodningen

For straks at forstå, når du modtager et svar fra serveren, om anmodningen var vellykket og for at videregive den til den relevante handler, er det nok at bruge "succes"-succestokenet. Det enkleste serversvar, der ikke indeholder nogen data, ville se sådan ud:

POST /api/v1/articles/22/publish ("succes": sand)

Fejl - fejldetaljer

Hvis anmodningen mislykkes - vi taler om årsagerne og typerne af negative serversvar lidt senere - tilføjes "fejl"-attributten til svaret, der indeholder HTTP-statuskoden og teksten til fejlmeddelelsen. Undlad venligst at forveksle med beskeder om valideringsfejl data for specifikke felter. Det er efter min mening mest korrekt at returnere statuskoden i svarheaderen, men jeg har også set en anden tilgang - returner altid status 200 (succes) i headeren, og send detaljer og eventuelle fejldata i brødteksten respons.

GET /api/v1/bruger ("succes": falsk, "fejl": ("kode": 401, "meddelelse": "Autorisering mislykkedes"))

Data - data returneret af serveren

De fleste serversvar er designet til at returnere data. Afhængigt af typen af ​​anmodning og dens succes, vil det forventede datasæt variere, men "data"-attributten vil være til stede i langt de fleste svar.

Eksempel på data returneret, hvis det lykkedes. I dette tilfælde indeholder svaret det anmodede brugerobjekt.

GET /api/v1/user ( "success": true, "data": ( "id" : 125, "email" : "[email protected]", "name" : "John", "efternavn" : "Smith", ) )

Et eksempel på de data, der returneres i tilfælde af en fejl. I dette tilfælde indeholder den feltnavne og valideringsfejlmeddelelser.

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

Paginering - oplysninger, der er nødvendige for at organisere sidenavigation

Ud over selve dataene, i svar, der vender tilbage sæt af samlingselementer, skal oplysninger om sidenavigation (paginering) baseret på forespørgselsresultaterne være til stede.

Det mindste sæt værdier for paginering består af:

• samlede antal poster;
• antal sider;
• aktuelle sidetal;
• antal poster pr. side;
• det maksimale antal poster pr. side, der understøttes af serversiden.

Nogle webudviklere API'erne inkluderer også i pagineringen et sæt færdige links til tilstødende sider, såvel som den første, sidste og nuværende.

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

Arbejd på fejl

Som nævnt ovenfor er det ikke alle anmodninger til web-API'en, der lykkes, men dette er også en del af spillet. Fejlrapporteringssystemet er kraftfuldt værktøj, lette klientens arbejde og guide klientansøgningen ad den rigtige vej. Ordet "fejl" i denne sammenhæng er ikke helt passende. Et bedre ord her ville være undtagelse, da anmodningen faktisk blev modtaget, parset, og et passende svar blev returneret, der forklarer, hvorfor anmodningen ikke kunne gennemføres.

Hvad er de potentielle årsager til de undtagelser, du modtager?

500 Intern serverfejl - alt er i stykker, men vi løser det snart

Dette er netop tilfældet, når problemet opstod på siden af ​​selve serveren, og klientapplikationen kun kan sukke og meddele brugeren, at serveren er træt og lægger sig til ro. For eksempel er forbindelsen til databasen tabt, eller der er en fejl i koden.

400 Dårlig anmodning - og nu er alt ødelagt for dig

Svaret er præcis det modsatte af det forrige. Returneres i tilfælde, hvor klientapplikationen sender en anmodning, der i princippet ikke kan behandles korrekt, ikke indeholder nødvendige parametre eller har syntaksfejl. Dette kan normalt løses ved at genlæse web-API-dokumentationen.

401 Uautoriseret - fremmed, identificer dig selv

Der kræves autorisation for at få adgang til denne ressource. At have autorisation garanterer naturligvis ikke, at ressourcen bliver tilgængelig, men uden autorisation vil du bestemt ikke vide det. Opstår, for eksempel, når du forsøger at få adgang til en privat del af API'en, eller når det aktuelle token er udløbet.

403 Forbudt - du er ikke tilladt her

Den anmodede ressource findes, men brugeren har ikke tilstrækkelige rettigheder til at se eller ændre den.

404 Ikke fundet - der bor ingen på denne adresse

Et sådant svar returneres som regel i tre tilfælde: stien til ressourcen er forkert (fejl), den anmodede ressource blev slettet og ophørte med at eksistere, den nuværende brugers rettigheder tillader ham ikke at vide om eksistensen af den ønskede ressource. For eksempel, mens vi kiggede gennem en liste over produkter, gik et af dem pludselig ud af mode og blev fjernet.

405 Metode ikke tilladt - du kan ikke gøre dette

Denne type undtagelse er direkte relateret til det verbum, der bruges i anmodningen (GET, PUT, POST, DELETE), hvilket igen indikerer den handling, vi forsøger at udføre med ressourcen. Hvis den anmodede ressource ikke understøtter den angivne handling, siger serveren det eksplicit.

422 Ubearbejdelig enhed - ret og send igen

En af de mest nyttige undtagelser. Returneres, når der er logiske fejl i anmodningsdataene. Med anmodningsdata mener vi enten et sæt parametre og deres tilsvarende værdier, der er bestået af GET-metoden, eller felter af et objekt, der er sendt i anmodningens brødtekst POST metoder, PUT og SLET. Hvis dataene ikke er blevet valideret, returnerer serveren en rapport i afsnittet "data" om, hvilke parametre der er ugyldige og hvorfor.

HTTP-protokollen understøtter meget større antal forskellige statuskoder til alle lejligheder, men i praksis bruges de sjældent og er i forbindelse med web-API'en til ingen praktisk nytte. I min hukommelse har jeg aldrig behøvet at gå ud over ovenstående liste over undtagelser.

Forespørgsler

Henter samlingsgenstande

En af de mest almindelige anmodninger er anmodningen om at få indsamlingselementer. Klientapplikationen viser informationsfeeds, produktlister, forskellige oplysninger og statistiske tabeller og meget mere ved at få adgang til indsamlingsressourcer. For at foretage denne anmodning får vi adgang til samlingen ved hjælp af GET-metoden og sender yderligere parametre i forespørgselsstrengen. Som vi allerede har angivet ovenfor, forventer vi som svar at modtage en række homogene samlingselementer og den nødvendige information til paginering - indlæsning af fortsættelsen af ​​listen eller dens specifikke side. Indholdet af udvalget kan særligt begrænses og sorteres ved hjælp af overførslen yderligere parametre. De vil blive diskuteret yderligere.

Sidenavigation

side- parameteren angiver, hvilken side der skal vises. Hvis denne parameter ikke godkendes, vises den første side. Fra det første vellykkede svar fra serveren vil det være klart, hvor mange sider samlingen har med de aktuelle filtreringsparametre. Hvis værdien overstiger det maksimale antal sider, er det bedst at returnere en fejl 404 Ikke fundet.

GET /api/v1/news?page=1

per Side- angiver det ønskede antal elementer på siden. Typisk har API'en egenværdi som standard, hvilket returnerer perSide som et felt i pagineringsafsnittet, men i nogle tilfælde giver dig mulighed for at øge denne værdi til rimelige grænser ved at give maksimal værdi maxPerPage:

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

Sortering af resultater

Ofte vil du sortere resultaterne af en markering ved stigende eller faldende værdier af bestemte felter, der understøtter komparativ (for numeriske felter) eller alfabetisk (for strengfelter) sortering. For eksempel skal vi organisere en liste over brugere efter navn eller produkter efter pris. Derudover kan vi indstille sorteringsretningen fra A til Z eller i modsat retning, og den er forskellig for forskellige felter.

Sorter efter- der er flere tilgange til at overføre komplekse sorteringsdata i GET-parametre. Her er det nødvendigt tydeligt at angive sorteringsrækkefølge og retning.

Nogle API'er foreslår at gøre dette som en streng:

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

Andre muligheder foreslår at bruge en matrix:

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

Generelt er begge muligheder ækvivalente, da de formidler de samme instruktioner. Efter min mening er muligheden med et array mere universel, men som de siger, det afhænger af smag og farve...

Enkel filtrering efter værdi

For at filtrere en markering efter værdien af ​​et felt, er det i de fleste tilfælde nok at sende feltnavnet og den påkrævede værdi som en filterparameter. For eksempel ønsker vi at filtrere artikler efter forfatter-id:

GET /api/v1/articles?authorId=25

Avancerede filtreringsmuligheder

Mange grænseflader kræver mere komplekse filtrerings- og søgesystemer. Jeg vil liste de vigtigste og mest almindelige filtreringsmuligheder.

Filtrering efter øvre og nedre grænser ved hjælp af sammenligningsoperatorer fra (større end eller lig med), højere (større end), til (mindre end eller lig med), lavere (mindre end). Gælder for felter, hvis værdier kan rangeres.

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

Filtrer efter flere mulige værdier fra listen. Gælder for felter, hvis sæt af mulige værdier er begrænset, for eksempel et filter af flere statusser:

GET /api/v1/products?status=1&status=2

Filtrering efter delvis strengmatch. Gælder for felter, der indeholder tekstdata eller data, der kan sidestilles med tekst, såsom numeriske produkt-SKU'er, telefonnumre mv.

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

Navngivne filtre

I nogle tilfælde, når visse sæt filterparametre ofte bruges og antydes af systemet som noget holistisk, især hvis de påvirker den interne, ofte komplekse mekanik af prøvetagning, er det tilrådeligt at gruppere dem i såkaldte navngivne filtre. Det er nok at videregive filternavnet i anmodningen, og systemet opbygger valget automatisk.

GET /api/v1/products?filters=anbefales

Navngivne filtre kan også have deres egne parametre.

GET /api/v1/products?filters=kidds

I dette underafsnit forsøgte jeg at tale om de mest populære muligheder og metoder til at opnå den nødvendige prøve. Mest sandsynligt vil der i din praksis være mange flere eksempler og nuancer vedrørende dette emne. Hvis du har noget at tilføje til mit materiale, vil jeg kun blive glad. I mellemtiden er posten allerede vokset til et betydeligt omfang, så vi vil analysere andre typer anmodninger i den næste tilnærmelse.

Udtrykket "klient-server" kan beskrive Hardware og betyder i dette tilfælde netværksforbundne server- og klientcomputere eller en måde at organisere software og tjenester på et netværk.

Klient-server-model (klient/server) – en computermodel, hvor behandlingen indlæses applikationsprogrammer fordelt mellem en klientcomputer og en servercomputer, der deler information via et netværk. Denne model kombinerer fordelene ved centraliseret databehandling og klientmodellen. Typisk er en klient slutbrugersoftware, der kører på WS og er i stand til at kommunikere med en server (normalt en databaseserver). Ydeevne ved brug af klient-server-modellen er højere end normalt, da klienten og serveren deler databehandlingsbelastningen. Klient-server-modellen fungerer bedst ved adgang til store mængder data.

Klient-server-arkitektur er en måde at organisere interaktionen mellem programmer eller komponenter i et multikomponentprogram på, hvilket indebærer tilstedeværelsen af ​​et program eller programkomponent kaldet en server og en eller flere andre komponenter kaldet klienter.

En klient er en lokal netværkskomponent, der anmoder om tjenester fra en server, og en server er en lokal netværkskomponent, der leverer tjenester til nogle klienter. Den lokale netværksserver leverer ressourcer (tjenester) til arbejdsstationer og/eller andre servere. I et klient-server-system sender klienten en anmodning til serveren, og al informationsbehandling foregår på serveren.

Kernen i klient/server-arkitekturen er databaseserveren (et system, der modtager anmodninger fra klientprogrammer over et computernetværk og svarer med de anmodede data (et sæt svar); hver databaseserver består af en computer, operativ system og DBMS-serversoftware), som er en applikation, der udfører et sæt datastyringshandlinger: eksekvering af forespørgsler, lagring og sikkerhedskopiering af data, sporing af referenceintegritet, kontrol af brugerrettigheder og privilegier og vedligeholdelse af en transaktionslog. Typisk sender klienter over et computernetværk anmodninger til serveren i form af sætninger i SQL-sprog. Serveren fortolker dem og sender de tilsvarende data tilbage til klienten.

Klienten har mulighed for at starte udførelsen af ​​serverprocedurer asynkront for serveren og modtage resultaterne af deres eksekvering. Typisk tillader en klient-server-arkitektur flere klienter at interagere med en server parallelt og uafhængigt af hinanden.

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

En databaseserver, der styrer datalagring, adgang og sikkerhed, sikkerhedskopier, overvåger dataintegritet i henhold til forretningsregler og, vigtigst af alt, opfylder klientforespørgsler;

En klient, der leverer en brugergrænseflade, udfører applikationslogik, validerer data, sender anmodninger til serveren og modtager svar fra den;

Netværks- og kommunikationssoftware, der kommunikerer mellem klient og server ved hjælp af netværksprotokoller.

DB, om strukturel Sprog SQL-forespørgsler (Structured Query Language), som er industristandard i relationsdatabasernes verden. Fjernserver accepterer anmodningen og videresender den til SQL-databaseserveren. SQL server – særligt program, som administrerer fjerndatabasen. SQL-serveren giver fortolkning af anmodningen, dens eksekvering i databasen, generering af resultatet af anmodningen og levering af den til klientapplikationen. I dette tilfælde er klientcomputerens ressourcer ikke involveret i den fysiske udførelse af anmodningen; klientcomputeren sender kun en anmodning til serverdatabasen og modtager resultatet, hvorefter den fortolker det som nødvendigt og præsenterer det for brugeren. Da resultatet af anmodningen sendes til klientapplikationen, "rejser" kun de data, som klienten har brug for, gennem netværket. Som følge heraf reduceres belastningen på netværket. Da anmodningen udføres, hvor dataene er lagret (serveren), er der ingen grund til at sende store batches af data. Derudover optimerer SQL-serveren, hvis det er muligt, den modtagne forespørgsel, så den udføres på minimum tid med den mindste overhead [[3.2], [3.3]]. systemet er vist i fig. 3.3.

Alt dette øger systemets ydeevne og reducerer den tid, det tager at vente på et anmodningsresultat. Når forespørgsler udføres af serveren, øges graden af ​​datasikkerhed markant, da dataintegritetsregler er defineret i databasen på serveren og er ens for alle applikationer, der bruger denne database. Dette eliminerer muligheden for at definere modstridende regler for opretholdelse af integritet. Den kraftfulde transaktionsmotor understøttet af SQL-servere gør det muligt at forhindre samtidige ændringer af de samme data af forskellige brugere og giver mulighed for at rulle tilbage til de oprindelige værdier, når der foretages ændringer i databasen, der endte unormalt [[3.2], [ 3.3]].

Ris. 3.3. Klient-server arkitektur

• Der er et lokalt netværk bestående af klientcomputere, som hver har en klientapplikation installeret til at arbejde med databasen.
• På hver af klientcomputerne har brugerne mulighed for at køre applikationen. Ved at bruge brugergrænsefladen fra applikationen starter den et opkald til DBMS'et på serveren for at hente/opdatere information. Til kommunikation anvendes et særligt forespørgselssprog SQL, dvs. Kun anmodningsteksten sendes over netværket fra klienten til serveren.
• DBMS initierer opkald til data, der er placeret på serveren, hvorved al databehandling udføres på serveren, og kun resultatet af anmodningen kopieres til klientcomputeren. Således returnerer DBMS resultatet til applikationen.

Lad os se på, hvordan adskillelsen af ​​funktioner mellem serveren og klienten ser ud.

• Klientapplikationsfunktioner:
  • Sender anmodninger til serveren.
  • Fortolkning af forespørgselsresultater modtaget fra serveren.
  • Præsentation af resultaterne for brugeren i en eller anden form (brugergrænseflade).
• Server side funktioner:
  • Modtagelse af anmodninger fra klientapplikationer.
  • Fortolkning af anmodninger.
  • Optimering og eksekvering af databaseforespørgsler.
  • Sender resultater til klientapplikationen.
  • Sikring af et sikkerhedssystem og adgangskontrol.
  • Databaseintegritetsstyring.
  • Implementering af stabilitet af multi-user driftstilstand.

Såkaldte "industrielle" DBMS'er opererer i klient-server-arkitekturen. De kaldes industrielle, fordi det er denne klasses DBMS, der kan levere arbejdet informationssystemer omfanget af en mellemstor og stor virksomhed, organisation, bank. Kategorien af ​​industrielle DBMS omfatter MS SQL Server, Oracle, Gupta, Informix, Sybase, DB2, InterBase og en række andre [[3.2]].

Som regel vedligeholdes en SQL-server af en individuel medarbejder eller en gruppe medarbejdere (SQL-serveradministratorer). De administrerer de fysiske karakteristika af databaser, udfører optimering, konfiguration og omdefinering forskellige komponenter databaser, oprette nye databaser, ændre eksisterende osv., og også udstede privilegier (tilladelser til et vist niveau af adgang til specifikke databaser, SQL-server) til forskellige brugere [[3.2]].

Lad os se på de vigtigste fordele ved denne arkitektur sammenlignet med filserverarkitekturen:

• Netværkstrafikken er væsentligt reduceret.
• Kompleksiteten af ​​klientapplikationer reduceres (det meste af belastningen falder på serverdelen), og som følge heraf reduceres kravene til hardwarekapaciteten på klientcomputere.
• Tilgængelighed af særlige softwareværktøj– SQL server – fører til, at en væsentlig del af design- og programmeringsopgaverne allerede er løst.
• Integriteten og sikkerheden af ​​databasen øges markant.

Ulemper omfatter højere finansielle udgifter til hardware og software, og også det faktum, at et stort antal klientcomputere placeret forskellige steder volder visse vanskeligheder med rettidig opdatering klientapplikationer på alle klientcomputere. Klient-server-arkitekturen har dog bevist sig i praksis, i i øjeblikket Der er et stort antal databaser bygget i overensstemmelse med denne arkitektur.

3.4. Tre-lags (multi-tier) klient-server-arkitektur.

Tre-link (i nogle tilfælde multi-link) arkitektur(N-tier eller multi- tre-lags arkitektur? Nu, når forretningslogikken ændrer sig, er der ikke længere behov for at ændre klientapplikationer og opdatere dem for alle brugere. Derudover reduceres kravene til brugerudstyr mest muligt.

Derfor er arbejdet struktureret som følger:

• Databasen i form af et sæt filer er placeret på harddisken på en specielt dedikeret computer (netværksserver).
• DBMS er også placeret på netværksserveren.
• Der er en specielt dedikeret applikationsserver, hvorpå forretningsanalysesoftwaren (forretningslogik) er placeret [[3.1]].
• Der er mange klientcomputere, som hver har en såkaldt "tynd klient" installeret - en klientapplikation, der implementerer brugergrænsefladen.
• På hver af klientcomputerne har brugerne mulighed for at køre en applikation – en tynd klient. Ved at bruge brugergrænsefladen fra applikationen starter den et opkald til business intelligence-softwaren på applikationsserveren.
• Applikationsserveren analyserer brugerkrav og genererer forespørgsler til databasen. Til kommunikation anvendes et særligt forespørgselssprog SQL, dvs. Kun anmodningsteksten sendes over netværket fra applikationsserveren til databaseserveren.
• DBMS'et indkapsler i sig selv al information om den fysiske struktur af databasen placeret på serveren.
• DBMS initierer opkald til data placeret på serveren, som et resultat af hvilket resultatet af forespørgslen kopieres til applikationsserveren.
• Applikationsserveren returnerer resultatet til klientapplikationen (brugeren).
• Applikationen viser ved hjælp af brugergrænsefladen resultatet af forespørgslerne.