REST

REST (ot angl. Representational State Transfer -- <> ili <>) -- arkhitekturnyi stil' vzaimodeistviia komponentov raspredelionnogo prilozheniia v seti. Drugimi slovami, REST -- eto nabor pravil togo, kak programmistu organizovat' napisanie koda servernogo prilozheniia, chtoby vse sistemy legko obmenivalis' dannymi i prilozhenie mozhno bylo masshtabirovat'^[1]. REST predstavliaet soboi soglasovannyi nabor ogranichenii, uchityvaemykh pri proektirovanii raspredelionnoi gipermedia-sistemy. V opredelionnykh sluchaiakh (internet-magaziny, poiskovye sistemy; prochie sistemy, osnovannye na dannykh) eto privodit k povysheniiu proizvoditel'nosti i uproshcheniiu arkhitektury. V shirokom smysle^[utochnit'] komponenty v REST vzaimodeistvuiut napodobie vzaimodeistviia klientov i serverov vo Vsemirnoi pautine. REST iavliaetsia al'ternativoi RPC^[2].

REST-zapros predstavliaet soboi obychnyi HTTP-zapros (obychno GET ili POST), a neobkhodimye dannye peredaiutsia v kachestve parametrov zaprosa^[3][4].

Dlia veb-sluzhb, postroennykh s uchiotom REST (to est' ne narushaiushchikh nakladyvaemykh im ogranichenii), primeniaiut termin <<RESTful>>.

V otlichie ot veb-servisov (veb-sluzhb) na osnove SOAP, ne sushchestvuet <> standarta dlia RESTful veb-API. Delo v tom, chto REST iavliaetsia arkhitekturnym stilem, v to vremia kak SOAP iavliaetsia protokolom. Nesmotria na to, chto REST ne iavliaetsia standartom sam po sebe, bol'shinstvo RESTful-realizatsii ispol'zuet takie standarty, kak HTTP, URL, JSON i, rezhe, XML. RESTful API ispol'zuiutsia dlia avtomatizirovannogo vzaimodeistviia mezhdu sistemami v razlichnykh oblastiakh, vkliuchaia upravlenie domennymi imenami, khostingom i sertifikatami bezopasnosti.^[5]

Khotia dannaia kontseptsiia lezhit v samoi osnove Vsemirnoi pautiny, termin <> byl vvedion Roem Fildingom, odnim iz sozdatelei protokola <<HTTP>>, lish' v 2000 godu^[4]. V svoei dissertatsii <> (<>)^[6] v Kaliforniiskom universitete v Irvaine^[3] on podviol teoreticheskuiu osnovu pod sposob vzaimodeistviia klientov i serverov vo Vsemirnoi pautine, abstragirovav ego i nazvav <> (<>>). Filding opisal kontseptsiiu postroeniia raspredelionnogo prilozheniia, pri kotoroi kazhdyi zapros (REST-zapros) klienta k serveru soderzhit v sebe ischerpyvaiushchuiu informatsiiu o zhelaemom otvete servera (zhelaemom predstavitel'nom sostoianii) i server ne obiazan sokhraniat' informatsiiu o sostoianii klienta (<>).

Stil' <> razvivalsia parallel'no s <<HTTP 1.1>>, razrabotannym v 1996--1999 godakh, osnovyvaias' na sushchestvuiushchem dizaine <<HTTP 1.0>>, razrabotannom v 1996 godu^[7].

Svoistva arkhitektury, kotorye zavisiat ot ogranichenii, nalozhennykh na REST-sistemy:

• Proizvoditel'nost': vzaimodeistvie komponentov sistemy mozhet iavliat'sia dominiruiushchim faktorom proizvoditel'nosti i effektivnosti seti s tochki zreniia pol'zovatelia;
• Masshtabiruemost' dlia obespecheniia bol'shogo chisla komponentov i vzaimodeistvii komponentov.

Roi Filding (odin iz glavnykh avtorov spetsifikatsii protokola HTTP) opisyvaet vliianie arkhitektury REST na masshtabiruemost' sleduiushchim obrazom:

• Prostota unifitsirovannogo interfeisa;
• Otkrytost' komponentov k vozmozhnym izmeneniiam dlia udovletvoreniia izmeniaiushchikhsia potrebnostei (dazhe pri rabotaiushchem prilozhenii);
• Prozrachnost' sviazei mezhdu komponentami sistemy dlia servisnykh sluzhb;
• Perenosimost' komponentov sistemy putiom peremeshcheniia programmnogo koda vmeste s dannymi;
• Nadiozhnost', vyrazhaiushchaiasia v ustoichivosti k otkazam na urovne sistemy pri nalichii otkazov otdel'nykh komponentov, soedinenii ili dannykh.^[3]

Sushchestvuet piat' obiazatel'nykh^[8][9] ogranichenii dlia postroeniia raspredelionnykh REST-prilozhenii po Fildingu^[3][10], i odno neobiazatel'noe.

Nakladyvaemye ogranicheniia opredeliaiut rabotu servera v tom, kak on mozhet obrabatyvat' i otvechat' na zaprosy klientov. Deistvuia v ramkakh etikh ogranichenii, sistema priobretaet takie zhelatel'nye svoistva, kak proizvoditel'nost', masshtabiruemost', prostota, sposobnost' k izmeneniiam, perenosimost', otslezhivaemost' i nadiozhnost'.

Esli servis-prilozhenie narushaet liuboe iz etikh ogranichitel'nykh uslovii, dannuiu sistemu nel'zia schitat' REST-sistemoi^[3].

Obiazatel'nymi usloviiami-ogranicheniiami iavliaiutsia:

Pervym ogranicheniem, primenimym k gibridnoi modeli, iavliaetsia privedenie arkhitektury k modeli klient-server. Razgranichenie potrebnostei iavliaetsia printsipom, lezhashchim v osnove dannogo nakladyvaemogo ogranicheniia. Otdelenie potrebnosti interfeisa klienta ot potrebnostei servera, khraniashchego dannye, povyshaet perenosimost' koda klientskogo interfeisa na drugie platformy, a uproshchenie servernoi chasti uluchshaet masshtabiruemost'. Naibol'shee zhe vliianie na vsemirnuiu pautinu, pozhalui, imeet samo razgranichenie, kotoroe pozvoliaet otdel'nym chastiam razvivat'sia nezavisimo drug ot druga, podderzhivaia potrebnosti v razvitii interneta so storony razlichnykh organizatsii.^[3]

Protokol vzaimodeistviia mezhdu klientom i serverom trebuet sobliudeniia sleduiushchego usloviia: v period mezhdu zaprosami klienta nikakaia informatsiia o sostoianii klienta na servere ne khranitsia (Stateless protocol ili <>). Vse zaprosy ot klienta dolzhny byt' sostavleny tak, chtoby server poluchil vsiu neobkhodimuiu informatsiiu dlia vypolneniia zaprosa. Sostoianie sessii pri etom sokhraniaetsia na storone klienta^[3]. Informatsiia o sostoianii sessii mozhet byt' peredana serverom kakomu-libo drugomu servisu (naprimer, v sluzhbu bazy dannykh) dlia podderzhaniia ustoichivogo sostoianiia, naprimer, na period ustanovleniia autentifikatsii. Klient initsiiruet otpravku zaprosov, kogda on gotov (voznikaet neobkhodimost') pereiti v novoe sostoianie.

Vo vremia obrabotki klientskikh zaprosov schitaetsia, chto klient nakhoditsia v perekhodnom sostoianii. Kazhdoe otdel'noe sostoianie prilozheniia predstavleno sviaziami, kotorye mogut byt' zadeistvovany pri sleduiushchem obrashchenii klienta.

Kak i vo Vsemirnoi pautine, klienty, a takzhe promezhutochnye uzly, mogut vypolniat' keshirovanie otvetov servera. Otvety servera, v svoiu ochered', dolzhny imet' iavnoe ili neiavnoe oboznachenie kak keshiruemye ili nekeshiruemye s tsel'iu predotvrashcheniia polucheniia klientami ustarevshikh ili nevernykh dannykh v otvet na posleduiushchie zaprosy. Pravil'noe ispol'zovanie keshirovaniia sposobno chastichno ili polnost'iu ustranit' nekotorye problemy klient-servernogo vzaimodeistviia, eshchio bol'she povyshaia proizvoditel'nost' i masshtabiruemost' sistemy.

Nalichie unifitsirovannogo interfeisa iavliaetsia fundamental'nym trebovaniem dizaina REST-servisov^[3]. Unifitsirovannye interfeisy pozvoliaiut kazhdomu iz servisov razvivat'sia nezavisimo.

K unifitsirovannym interfeisam pred'iavliaiutsia sleduiushchie chetyre ogranichitel'nykh usloviia^[11][12]:

Identifikatsiia resursov
Vse resursy identifitsiruiutsia v zaprosakh, naprimer, s ispol'zovaniem URI v internet-sistemakh. Resursy kontseptual'no otdeleny ot predstavlenii, kotorye vozvrashchaiutsia klientam. Naprimer, server mozhet otsylat' dannye iz bazy dannykh v vide HTML, XML ili JSON, ni odin iz kotorykh ne iavliaetsia tipom khraneniia vnutri servera.

Manipuliatsiia resursami cherez predstavlenie
Esli klient khranit predstavlenie resursa, vkliuchaia metadannye -- on obladaet dostatochnoi informatsiei dlia modifikatsii ili udaleniia resursa.

<> soobshcheniia
Kazhdoe soobshchenie soderzhit dostatochno informatsii, chtoby poniat', kakim obrazom ego obrabatyvat'. K primeru, obrabotchik soobshcheniia (parser), neobkhodimyi dlia izvlecheniia dannykh, mozhet byt' ukazan v spiske MIME-tipov^[3].

Gipermedia kak sredstvo izmeneniia sostoianiia prilozheniia (HATEOAS)
Klienty izmeniaiut sostoianie sistemy tol'ko cherez deistviia, kotorye dinamicheski opredeleny v gipermedia na servere (k primeru, giperssylki v gipertekste). Iskliuchaia prostye tochki vkhoda v prilozhenie, klient ne mozhet predpolozhit', chto dostupna kakaia-to operatsiia nad kakim-to resursom, esli ne poluchil informatsiiu ob etom v predydushchikh zaprosakh k serveru. Ne sushchestvuet universal'nogo formata dlia predostavleniia ssylok mezhdu resursami, Web Linking (RFC 5988 -> RFC 8288) i JSON Hypermedia API Language Arkhivnaia kopiia ot 27 iiunia 2014 na Wayback Machine iavliaiutsia dvumia populiarnymi formatami predostavleniia ssylok v REST HYPERMEDIA servisakh.

Klient obychno ne sposoben tochno opredelit', vzaimodeistvuet li on napriamuiu s serverom ili zhe s promezhutochnym uzlom, v sviazi s ierarkhicheskoi strukturoi setei (podrazumevaia, chto takaia struktura obrazuet sloi). Primenenie promezhutochnykh serverov sposobno povysit' masshtabiruemost' za schiot balansirovki nagruzki i raspredelionnogo keshirovaniia. Promezhutochnye uzly takzhe mogut podchiniat'sia politike bezopasnosti s tsel'iu obespecheniia konfidentsial'nosti informatsii^[13].

REST mozhet pozvolit' rasshirit' funktsional'nost' klienta za schiot zagruzki koda s servera v vide appletov ili skriptov. Filding utverzhdaet, chto dopolnitel'noe ogranichenie pozvoliaet proektirovat' arkhitekturu, podderzhivaiushchuiu zhelaemuiu funktsional'nost' v obshchem sluchae, no, vozmozhno, za iskliucheniem nekotorykh kontekstov.

Roi Filding ukazyval, chto prilozheniia, ne sootvetstvuiushchie privedionnym usloviiam, ne mogut nazyvat'sia REST-prilozheniiami. Esli zhe vse usloviia sobliudeny, to, po ego mneniiu, prilozhenie poluchit sleduiushchie preimushchestva^[3][10]:

• Nadiozhnost' (za schiot otsutstviia neobkhodimosti sokhraniat' informatsiiu o sostoianii klienta, kotoraia mozhet byt' uteriana);
• Proizvoditel'nost' (za schiot ispol'zovaniia kesha);
• Masshtabiruemost';
• Prozrachnost' sistemy vzaimodeistviia (osobenno neobkhodimaia dlia prilozhenii obsluzhivaniia seti);
• Prostota interfeisov;
• Portativnost' komponentov;
• Liogkost' vneseniia izmenenii;
• Sposobnost' evoliutsionirovat', prisposablivaias' k novym trebovaniiam (na primere Vsemirnoi pautiny).

• Erik Wilde, Cesare Pautasso. REST: From Research to Practice. -- Springer Science & Business Media, 2011. -- 528 p. -- ISBN 978-1-4419-8303-9.

• Roy Fielding. Architectural Styles and the Design of Network-based Software Architectures (angl.) (2000). Data obrashcheniia: 20 fevralia 2009. Arkhivirovano 15 maia 2012 goda.
• Cesare Pautasso; Olaf Zimmerman; Frank Leymann.: . RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision (angl.). 17th International World Wide Web Conference (WWW2008). Data obrashcheniia: 20 fevralia 2009. Arkhivirovano 15 maia 2012 goda.
• Dzhon Flanders. Vvedenie v sluzhby RESTful s ispol'zovaniem WCF . MSDN Magazine (ianvar' 2009). Data obrashcheniia: 20 fevralia 2009. Arkhivirovano 15 maia 2012 goda.
• Alex Rodriguez. RESTful Web services: The basics (angl.). IBM. Data obrashcheniia: 15 dekabria 2015. Arkhivirovano 22 dekabria 2015 goda.
• Todd Fredrich. REST API Tutorial (angl.). Data obrashcheniia: 27 oktiabria 2016. Arkhivirovano 25 fevralia 2017 goda.

• Arkhitektura programmnogo obespecheniia
• Veb 2.0
• Veb-programmirovanie
• Vsemirnaia pautina

• Vikipediia:Cite web (ne ukazan iazyk)
• Stranitsy, ispol'zuiushchie volshebnye ssylki ISBN
• Vikipediia:Stat'i, trebuiushchie utochneniia istochnikov
• Vikipediia:Stat'i s shablonami nedostatkov po alfavitu
• Vikipediia:Stat'i s razdelami bez ssylok na istochniki s marta 2017 goda
• Vikipediia:Stat'i bez istochnikov (ne raspredelionnye po tipam)
• Vikipediia:Cite web (zamenit' webcitation-arkhiv: deadlink no)
• Stranitsy, ispol'zuiushchie volshebnye ssylki RFC