РЕСТфул Сервицес ИИ део: Ограничења и циљеви

РЕСТфул Сервицес ИИ део: Ограничења и циљеви

У првом делу ове серије писао сам о ХТТП-у и његовим конструкцијама које се примењују на дизајн веб услуга.

ХТТП је само мали део онога што улази у писање модерних веб услуга.

Овај пост говори о томе како примените ове конструкције за стварање одрживих, робусних услуга.

Дефинисање РЕСТ

РЕСТ је скраћеница од РЕ презентацијски С тате Т рансфер. То је архитектонски стил. То значи да РЕСТ не намеће формални стандард да би утврдио да ли је веб услуга РЕСТфул. Уместо тога, он има скуп широких ограничења, од којих свако има одређени циљ на уму.

Ова ограничења је први увео Рои Фиелдинг, који је био један од коаутора ХТТП спецификације давне 2000. године.

Фиелдингова ограничења

Фиелдинг је створио ова ограничења са крајњим циљем да апликације учине бржим, поузданијим и лакшим за скалирање.

Као дизајнер веб услуга, ваша услуга би требало да се труди да што је могуће ближе поштује ова ограничења како би искористила њихове предности. Дакле, заронимо у њих.

Ограничење бр. 1: Архитектура клијент-сервер

Прво ограничење које је предложио РЕСТ је одвајање сервера од клијента. Требали бисте подстицати раздвајање забринутости између вашег сервера и клијената кад год је то могуће. Ваш циљ треба да буде максимизирање поделе рада - и минимизирање преклапања - између њих двоје.

Сервер или позадина је обично одговоран за чување трајних података ваше апликације, заједно са свом пословном логиком потребном за интеракцију са њим. То може укључивати аутентификацију корисника, ауторизацију, проверу података итд.

Клијент, или фронт енд , одговоран је за подношење захтева услузи, а затим ради нешто значајно са одговором који добије.

Клијент сам може бити веб услуга, у ком случају једноставно троши податке. Друга могућност је да је окренута ка кориснику. Пример за то би била веб или мобилна апликација. Овде је такође одговоран за представљање података кориснику и представљање интерфејса за корисникову интеракцију са њима .

Требали бисте бити у могућности да сваку од ове две компоненте третирате као црну кутију у односу једна на другу. На овај начин се могу самостално модификовати. Ово подстиче модуларност унутар апликације.

Овај концепт није јединствен за РЕСТФул апликације, па чак ни за веб апликације. Већина програмера ионако покушава да разбије своје пројекте на независне компоненте. Али, наводећи ово као изричито ограничење РЕСТфул дизајна, Фиелдинг даље подстиче ову праксу.

И на крају, смањење броја ствари за које је сервер одговоран смањује количину неопходне логике. То заузврат омогућава бољу скалабилност и повећане перформансе.

Ограничење бр. 2: апатрид

Следеће важно ограничење које РЕСТ предлаже је апатридије.

Уопштено говорећи, главни циљ службе без држављанства је да долазни захтеви постану самодовољни и извршавају их у потпуној изолацији.

Сваки захтев мора имати све информације које су серверу можда потребне да би га правилно обрадио и одговорио. Другим речима, сервер не треба да користи информације из претходних захтева. Одговорност за одржавање стања апликације клијента пребацује се на самог клијента.

Да бисте ово разумели, размотрите врло једноставну веб услугу која је одговорна за одговарање на корисникове упите за претрагу. Тачан приказ ентитета за којим се трага није битан. Важно је да, уместо да врати стотине резултата претраге једним потезом, сервер користи пагинацију : истовремено враћа само 10 резултата из произвољно великог скупа резултата.

У традиционалном „државном“ моделу развоја, сервер може бити дизајниран на такав начин да прати све своје клијенте, заједно са свим страницама којима су већ приступили.

И тако, када стигне захтев за новом страницом, сервер може потражити клијента у свом систему и одредити најновију страницу коју је примио.

Тада сервер може да одговори са следећом страном и ажурира свој систем тако да то одражава. То се наставља како клијент наставља навигацију низом резултата.

У алтернативном приступу без држављанства, одговорност за одржавање свог стања је децентрализована и пребачена на клијента. Клијент тада мора да наведе стварне бројеве страница жељеног резултата, за разлику од тражења следеће странице. На пример:

GET //my-awesome-web-service.com/pages/1GET //my-awesome-web-service.com/pages/3

Приступ без држављанства са собом доноси неколико главних предности. Прво, праћење стања клијента постаје све веће опорезивање сервера како се број клијената скалира.

Друго, и што је још важније, услуга без држављанства такође се лако дистрибуира . Ако је сервер одговоран за одржавање информација о стању апликације, такође је неопходно да се будући захтеви усмеравају на сервер који чува ове информације.

Ако постоје стотине сервера одговорних за обраду долазних захтева, онда мора постојати неки механизам који осигурава да захтеви од одређеног клијента увек заврше на одређеној инстанци сервера.

У случају да инстанца сервера падне, све информације о стању клијента које су биле ускладиштене на том серверу падају заједно са њим.

Наравно, могли бисте смислити архитектуру у којој инстанце сервера могу међусобно да деле податке. Али ово додаје прилично мало сложености.

Насупрот томе, услуга без држављанства олакшава додавање и уклањање инстанци сервера на ад хоц основи. Тада можете даље уравнотежити оптерећење између њих по потреби.

Будући да су сервери агностични према долазним захтевима, скалирање је само питање додавања више сервера у балансатор оптерећења. Слично томе, убијање сервера - намерно или на други начин - не утиче на поузданост услуге.

Наравно, ова једноставност кошта. Ако клијент уз сваки захтев приложи идентичне податке, потенцијални је извор вишка. Пропусни опсег није бесплатан, тако да све додатне информације које се преносе додају одређену количину трошкова.

Ограничење # 3: Кеш меморија

Треће ограничење је експлицитна предмеморија. Идеја је да се поруке враћене услугом означе као изричито предмемориране или непредмеморирајуће. Ако их је могуће предмеморисати, сервер би требало да утврди трајање одговора.

Ако клијент има приступ важећем кешираном одговору за дати захтев, избегава понављање истог захтева. Уместо тога, користи своју кеширану копију. Ово помаже у ублажавању дела сервера и на тај начин доприноси скалабилности и перформансама.

Ово је облик оптимистичне репликације - познат и као лења репликација - где услуга не покушава да гарантује 100% доследност између себе и својих клијената, осим ако није апсолутно критична. Уместо тога, чини ову жртву у замену за добитак у перципираним перформансама.

На пример, АПИ који одговара платформи за блогове може да одлучи да списак постова на блогу учини кешираним неколико минута ако зна да учесталост којом људи покушавају да приступе постовима далеко премашује учесталост стварања нових постова. Као резултат тога, корисницима се повремено могу представити застарели подаци, али систем у целини има боље резултате.

Наравно, могућност кеширања ресурса и његово трајање нису универзални и захтевају одређено разматрање. Ако сте погрешно одабрали, ово може фрустрирати ваше кориснике.

Веб услуге обично постижу могућност кеширања помоћу стандардног заглавља Цацхе-Цонтрол . Понекад то раде заједно са другим заглављима која је одредио ХТТП.

Заглавље Цацхе-Цонтрол ефикасно служи као прекидач, одређујући да ли прегледач треба да кешира дотични одговор.

Ресурсе означене као приватне кешира само клијент, па су стога ограничени само на тог клијента.

С друге стране, ресурсе означене као јавни може да предмеморише један или више посредничких посредника између услуге и клијента.

Као резултат, ови ресурси могу бити потенцијално сервирани за више корисника. Алтернативно, можете додати аргумент но-цацхе и потпуно зауставити било какво предмеморирање ресурса.

Ево како изгледа једно од ових заглавља Цацхе-Цонтрол:

Cache-Control: public;max-age=3431901

Заглавље вам такође омогућава да одредите трајање за које ресурс важи. Ово клијенту даје до знања када треба да престане да користи своју кеширану копију и затражи нову копију.

Ево логике која стоји иза овога:

Поред овога, ХТТП такође има успостављене механизме за извршавање онога што је познато као условни захтев. Циљ је овде да сервер клијенту врати одређене ресурсе само када су испуњени одређени услови .

Под претпоставком да клијент има сачувану копију ресурса у својој кеш меморији, он може упутити захтев серверу да утврди да ли постоји ажурирана копија тог истог ресурса. Ако је постоји, сервер враћа нову копију. У супротном, клијенту говори да настави да користи своју локалну копију.

Ово помаже у спречавању сувишног преноса података преко мреже, а истовремено осигурава да клијент има приступ свежим подацима у сваком тренутку.

ХТТП вам ово омогућава на неколико начина:

Приступ кеширању бр. 1: ако је измењен од / последња измена

Заједно са сваким одговором који сервер пошаље натраг, он може да одлучи да приложи последњу измену временске ознаке. Ово показује када је ресурс последњи пут промењен.

Када клијент треба да поново затражи ресурс у будућности, он захтев упућује серверу као и обично, али са одговарајућим заглављем Иф-Модифиед-Синце . То говори серверу да врати нову копију ресурса, ако постоји.

У супротном, сервер враћа статусни код 304, којиналаже клијенту да настави да користи копију коју већ има.

Приступ кеширању бр. 2: ако се не подудара / ЕТаг

Ова шема делује слично претходној, осим начина на који се ресурси идентификују. Уместо да користи временске ознаке, сервер са сваким одговором шаље јединствени хеш који објашњава стање ресурса у том тренутку (познато као ЕТаг).

За будуће захтеве, клијент шаље одговарајући ЕТаг серверу. Ако постоји ресурс са истим ЕТаг, сервер говори клијенту да настави да користи кеширану копију. У супротном, сервер враћа клијенту нови.

Кеширање је компликовано. Како ваша услуга почиње да додаје још корисника, желећете да сазнате више о кеширању и како га можете користити у своју корист.

Ограничење бр. 4: Јединствени интерфејс

Униформа интерфејс (или Јединствена уговор ) причаРЕСТфул услуга шта да послужи, у облику документа, слике, не-виртуелног објекта итд.

РЕСТ, међутим, не одређује начин на који ћете изаћи у интеракцију са овим ресурсима, под условом да су доследни и добро разумљиви.

Генерално, пре него што клијент може да ступи у интеракцију са услугом РЕСТфул, мора да се договори о:

  1. Идентификација: Мора постојати начин да се јединствено идентификују сви ресурси које услуга нуди.
  2. Манипулација: Мора постојати стандардни скуп операција које се могу изводити на било ком датом ресурсу са предвидљивим исходима. Резултати ових операција такође морају бити самоописни и јединствено разумљиви.

ХТТП, на пример, користи УРЛ адресе за идентификацију ресурса. Такође користи прегршт радњи глагола и добро документоване статусне кодове да олакша интеракцију са ресурсима. (За детаљније детаљно објашњење ХТТП-ових конструкција, можете се вратити и прочитати Део И ове серије.)

До овог тренутка сматрали смо да су услуге РЕСТфул строго везане за ХТТП. Што се тиче веб услуга, ово је готово увек тачно.

Али у теорији, РЕСТ се може применити преко било ког протокола који пружа пристојан начин за постизање два услова која сам горе описао. Из тог разлога, РЕСТ се понекад назива и РЕСТ преко ХТТП-а да би се појаснило да се користи преко веба.

Ограничење бр. 5: Слојевити систем

Слојевити систем се надовезује на ограничење клијент-сервер о којем смо раније разговарали и намеће још веће раздвајање забринутости. Укупна архитектура ваше услуге може се раздвојити у појединачне слојеве, од којих сваки служи одређеној функцији.

Још важније је да сваки слој мора деловати независно и да комуницира само са слојевима који су непосредно уз њега. Ово приморава захтеве да се шире на предвидљив начин, без заобилажења слојева.

На пример, за скалирање можете да користите прокси који се понаша као уравнотеживач оптерећења. Једина сврха проксија би тада била прослеђивање долазних захтева одговарајућој инстанци сервера.

Клијент, с друге стране, не мора бити свестан ове поделе. Једноставно наставља да подноси захтеве на исти УРЛ, не бринући се о детаљима како се захтеви обрађују.

Слично томе, у архитектури може постојати још један слој одговоран за предмеморирање одговора како би се минимализирао рад који сервер треба обавити.

Други слој се може понашати као мрежни пролаз и превести ХТТП захтеве у друге протоколе.

Један од начина на који бисте ово могли да употребите био би да примените ФТП сервер. Клијент би наставио да поставља захтеве ономе што он сматра ХТТП сервером, док ви заправо имате ФТП сервер који обавља посао испод хаубе.

Баш као и разлика клијент-сервер, ово слојевито системско ограничење минимизира ризик од повезивања функционалности у вашој услузи, али на штету додатних трошкова у систему.

Закључак

Да сумирамо ствари, погледали смо важна ограничења која бисте требали имати на уму приликом дизајнирања РЕСТфул веб услуга. Такође желим да нагласим да, иако су то технички тешки захтеви које услуга мора да испуни да би се могла сматрати РЕСТфул, у пракси се то не дешава увек.

Изградња стварних услуга више се бави решавањем проблема него испуњавањем техничких дефиниција. Као резултат, ова ограничења програмери и архитекте најчешће користе као смернице, који затим одлучују која ће правила следити у својим напорима да испуне своје специфичне циљеве.

Отуда потичу појмови делимично одморни и потпуно одморни. У ствари,већина услуга с којима се сусрећете на мрежи технички није у потпуности РЕСТфул.

У следећем, и последњем делу ове серије, разговараћу о принципима ХАТЕОАС-а, као и о Рицхардсон-овом моделу зрелости. Ово пружа мало квантитативни приступ одређивању колико је веб услуга РЕСТфул. Пронађите га овде!

Надам се да је ово био користан увод у оно што иде у прављење РЕСТфул апликације. Разумевање принципа РЕСТ-а сигурно ће вам помоћи када радите са пуно АПИ-ја независних произвођача. Или чак и када градите сопствене апликације на вебу, мобилном уређају или било где другде.

Као бонус, овде сам такође отпремио презентацију релевантну за ову тему. Клизач је позајмљен из кратког говора који сам одржао пре неколико месеци на свом универзитету под називом „Утицај РЕСТфул архитектуре на перформансе и скалабилност апликација“. Надам се да ће вам бити корисно :)

Обавестите ме у коментарима ако имате било какве повратне информације или слободно ме контактирајте путем мог ЛинкедИна.

Ево неколико извора за даље читање о РЕСТ-у:

Кључни принципи софтверске архитектуре - МСДН

Објашњен одмор, презентација

Рестфул Веб Сервицес - Сам Руби

ВхатИсРест.цом

Одмарајте се у пракси