1.4.2 Rest – ті қолдану

Сервистің ақпаратымен басқару – толығымен деректерді тасымалдау протоколында негізделеді. Ең тараған протокол ол – HTTP. Сондықтан HTTP үшін деректерге іс-әрекет келесі амалдармен беріледі: GET (алу), PUT (қосу, ауыстыру), POST (қосу, ауыстыру, өзгерту), DELETE (жою). Яғни ол қарапайым CRUD (Create-Read-Update-Delete) іс әрекеттері барлық төрт амалдармен де және тек GET және POST арқылы да орындала алады.

REST – ті қолдануды қарапайым мысал ретінде көрсетейік: GET /book/ — барлық кітаптардың тізімін алу

GET /book/3/ — 3 номердегі кітапты алу PUT /book/ — кітапты қосу (деректер сұраудың денесінде) POST /book/3 – кітапты өзгерту (деректер сұраудың денесінде) DELETE /book/3 – кітапты жою REST стилінің шектеулері Интернет жілісін басқаратын негізгі қағидаттарында негізделген. Ол келесі қағидаттар:

• Қолданушылардың агенттері әртүрлі болатын және аталатын ресурстармен әрекеттеседі. Әрбір ресурсқа ерекше URL идентификаторы арқылы сұрау салуға болады.

• Ресурстармен әрекеттесу (оладың URL-дері арқылы анықталатын) HTTP-дің стандартты командаларының бірыңғай интерфейсі (GET, POST, PUT және DELETE) арқылы жүзеге асады. Әрекеттесу үшін тағы да ресурстың мультимедиялық типін жариялау маңызды. Ол HTTP ішіндегісінің типінің атын белгілеу арқылы жүзеге асады (XHTML, XML, JPG, PNG и JSON – белгілі мультимедиялық типтер).

• Ресурстар өзін өзі сипаттайды. Ресурстың сұрауын өңдеуге қажетті ақпарат сұраудың өзінде болады (бұл сервистердің қалпын сипаттамау мүмкіндігін береді).

• Ресурстарда басқа ресурстарға сілтеу болады(гиперорта).

REST архитектуралық стилі көрініп тұрғандай қолданыста өте жеңіл. Келген сұрау бойынша, қай форматтарда екенін анықтамай(SOAP6 XML-RPC-дан қарағанда) бірден не стейтінін анықтауға болады. Деректер қосалқы қабаттарды қолданбай ақ жіберіледі. Сондықтан REST қор жағынан жеңіл, себебі сұрауға не стейтінін білу үшін парсинг жасау керек емес және деректерді бір форматтан екіншіге аудару қажет емес. REST архитектуралық стиліндегі сервистердің тағы бір ерекше құндылығы болып есептелінетін ол осы сервистермен кез келген жүйе және платформа жұмыс істей алады. Яғни ол платформаға тәуелсіз, себебі XML – ге парсинг жүргізу және HTTP сұрауларын жүргізу барлық жерде кездеседі.

2 Soa бағдарламалау

2.1 Тарихы

SOA (Service Oriented Architecture) немесе қызметке(сервиске) бағдарланған архитектура, - қызмет немесе сервис деп аталатын,қосымша белгіленген тәртіппен функционалды код элементіне ұйымдасқан, бағдарламалық жасақтаманы бағдарлау стилі және архитектуралық тәсіл.

Тарихқа жүгініп бағдарламалаудың эволюциясын қарасақ, бізге белгілі ең алдымен құрылымдық, одан кейін объектілі бағытталған, әрі қарай компонентті бағытталған бағдарламалау тілдері болды. Бағдарламалаудың дамуы барысында бір заңдылықты байқауға болады: әрбір жаңа методологиялық және технологиялық ұрпақ өзінің негізін салушылардың қадір-қасиетін қосып, кемшіліктерін түзейді. Соған қарамастан әрбір жаңа ұрпақ солай ақ жаңа мәселелерді тудырады. Былайша айтқанда, қазіргі заманғы бағдарламалау логикалық байлаулардың үзілуіне тұрақты үрдісінің үзіліссіз жаңартылуы болып табылады.

Логикалық байлаулардың болуы жаман, бірақ одан айналып өту мүмкін емес. Логиқалық байлаулардан айырылған қосымша еш пайда тигізбейді. Оның практикалық маңыздылығы тек логикалық байлауларының пайда балуымен қалыптасады. Бағдарламалық кодты жазудың өзі бір мәннің екінші мәнге логикалық байлауын көрсетеді.

Өткен күндердің мәселелері ескеріліп, XX ғасырдың аяғында объектілі және компонентті бағдарламалаудың мәселелерін шешу керек болатын, жаңа сервисті бағытталған (SOA) методология пайда болды. Сервисті бағытталған қосымшада құрастырушы өзінің күшін бизнес логиканы жасауға және оған өзара алмасатын соңғы нүктелер арқылы рұқсат беруге жұмсайды. Клиент сервистің кодымен немесе кабымен емес, соңғы нүктелермен жұмыс істейді. Клиенттер мен сервистің соңғы нүктесі арасындағы әрекеттесу стандартты хабарламалармен алмасу механизмінде негізделеді, ал сервис сол сервис не істей алатынын және клиенттер операцияларды қалай шақыру керек екенін туралы метадеректердің бір түрін жариялайды.

Көптеген қарым қатынаста сервистер компоненттердің нақтылы эволюциялық нәтижесі болып табылады. Сол сияқты кезінде объектілер компоненттердің нақтылы эволюциясы болған.