ИнтеRESTни уеб услуги

1,729 views

Published on

REST (Representational State Transfer) е архитектурен стил за изграждане на лесни, разбираеми
и мащабируеми уеб услуги (web services). За мнозина разработчици уеб услугите предизвикват
неприятни (меко казано) чувства1. Това е така, защото тежките решения за предоставяне на
услуги в уеб (например SOAP) са неудобни и сложни за прилагане и изискват допълнително
разучаване на множество други технологии. REST се базира на фундаментите на уеб: HTTP, URI
и XHTML – и може да да се реализира с всеки език за програмиране на уеб или платформа.
Аудиторията ще бъде запозната с помощта на примери с основните принципи за изграждане
на услуги чрез методологията на REST. Ще бъдат подчертани предимствата и възможностите на
услугите. Ще бъде показано защо този стил набира все по-голяма популярност и защо големи
компании като Amazon, Ebay, Google предоставят главно REST-базирани услуги. Ще бъде
демонстрирано AJAX приложение като клиент на REST уеб услуга предоставена от Ruby on Rails
и Java Restlet приложение.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,729
On SlideShare
0
From Embeds
0
Number of Embeds
43
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Theme created by Sakari Koivunen and Henrik Omma Released under the LGPL license.
  • ИнтеRESTни уеб услуги

    1. 1. Инте REST ни уеб усуги Свилен Иванов (svilen.ivanov@gmail.com) (http://svilen-online.blogspot.com) УебТех 2007, Варна 30 юни
    2. 2. Преди да започна... <ul><li>С какво ще се опитам да задържа Вашето внимание: </li></ul><ul><ul><li>познати или непознати възможности на HTTP протокола </li></ul></ul><ul><ul><li>разбираем начин за предоставяне на уеб услуги </li></ul></ul><ul><ul><li>как да осигурим мащабируемост (scalability) и надеждност на приложенията </li></ul></ul><ul><ul><li>как лесно да интегрираме няколко приложения </li></ul></ul>
    3. 3. Какво е „уеб услуга“? <ul><li>Уеб услугите могат да бъдат разгледани като уеб страници предназначени за „компютри“ </li></ul><ul><li>Приложенията-клиенти на уеб услуга биха могли да обработят („разберат“) предоставената информацията </li></ul>
    4. 4. Какво не е наред с уеб услугите? <ul><li>Изискват от разработчика да учат нови технологии: </li></ul><ul><ul><li>SOAP, WSDL, UDDI, WS-Security, WS-Reliability, WS-ReliableMessaging, WS-Addressing, WS-Transaction </li></ul></ul><ul><li>Обвързват програмиста с продукти на големи компании </li></ul><ul><ul><li>не се толерират реализации със свободен софтуер </li></ul></ul><ul><li>Сложни технологии </li></ul><ul><ul><li>защото трябва да решават сложни проблеми </li></ul></ul>
    5. 5. Какви услуги искаме? <ul><li>За прости услуги споменатите технологии са прекалено голямо усилие </li></ul><ul><li>Какви услуги могат да бъдат наречени „прости“: </li></ul><ul><ul><li>действия, които са достъпни за потребителя: </li></ul></ul><ul><ul><ul><li>блог – добавяне, изтриване или редактиране на статия, редактиране на коментари, търсене по ключови думи, RSS/PDF вариант на статиите </li></ul></ul></ul><ul><ul><ul><li>фото сайт - добавяне, изтриване или редактиране на снимки, достъп до различни по размери варианти на снимката, EXIF информацията; подреждане на снимките по фото албуми </li></ul></ul></ul>
    6. 6. С какво разполагаме? <ul><li>Разработчиците познават (X)HTML и CSS: </li></ul><ul><ul><li>не се плашат от малко XML </li></ul></ul><ul><ul><li>някои предпочитат JSON </li></ul></ul><ul><li>Запознати с HTTP протокола </li></ul><ul><ul><li>URI (URL) </li></ul></ul><ul><ul><li>методи GET, POST </li></ul></ul><ul><ul><li>заглавие на заявката: content-type, cookies </li></ul></ul><ul><li>XMLHttpRequest </li></ul>
    7. 7. Архитектура ориентирана към ресурси <ul><li>Ресурси </li></ul><ul><ul><li>самостоятелна единица информация, която има смисъл сама по себе си </li></ul></ul><ul><li>Примери </li></ul><ul><ul><li>последната написана статия в блог </li></ul></ul><ul><ul><li>списък със статии написани 25 юни 2007 </li></ul></ul><ul><ul><li>статии отбелязани с етикета „webtech“ </li></ul></ul><ul><ul><li>статията „Уебтех във Варна“ </li></ul></ul><ul><ul><li>петия коментар към статията „Уебтех във Варна“ </li></ul></ul><ul><ul><li>списък с коментари за дадена статия </li></ul></ul>
    8. 8. Ресурси и URIs <ul><li>Ресурсите могат да бъдат представени с (поне едно) URI </li></ul><ul><li>Примери </li></ul><ul><ul><li>последната написана статия в блог: http://example.com/svi/posts/latest </li></ul></ul><ul><ul><li>списък със статии написани 25 юни 2007: http://example.com/svi/posts/2007/06/25 </li></ul></ul><ul><ul><li>статии отбелязани с етикета „webtech“c http://example.com/svi/tags/webtech </li></ul></ul>
    9. 9. Ресурси и URIs <ul><li>Примери: </li></ul><ul><ul><li>Статия „Уебтех във Варна“: http://example.com/svi/webtech-in-varna </li></ul></ul><ul><ul><li>Коментари към статия „Уебтех във Варна“: http://example.com/svi/webtech-in-varna/ ↵ comments </li></ul></ul><ul><ul><li>петия коментар към статията http://example.com/svi/webtech-in-varna/ ↵ comments/5 </li></ul></ul><ul><ul><li>статията като PDF: http://example.com/svi/webtech-in-varna/pdf </li></ul></ul>
    10. 10. Манипулиране на ресурсите <ul><li>Изпълнение на HTTP заявка с подходящ метод </li></ul><ul><ul><li>„метод“ като във <form method=“post“....> </li></ul></ul><ul><ul><li>GET, POST са по-известни от PUT, DELETE, HEAD, OPTIONS </li></ul></ul><ul><li>Видове манипулиране </li></ul><ul><ul><li>Извличане на ресурс: HTTP GET </li></ul></ul><ul><ul><li>Създаване на нов ресурс: HTTP POST или PUT </li></ul></ul><ul><ul><li>Модифициране на ресурс: HTTP PUT </li></ul></ul><ul><ul><li>Изтриване на ресурс: HTTP DELETE </li></ul></ul><ul><ul><li>Извличане на част от информацията: HEAD </li></ul></ul>
    11. 11. Пример: опростен блог <ul><li>Ресурси: </li></ul><ul><ul><li>Основния ресурс е съвкупност от статии (post) </li></ul></ul><ul><ul><li>Представяния: </li></ul></ul><ul><ul><ul><li>Списък на заглавията на всички статии като HTML http://localhost:3000/svi/posts </li></ul></ul></ul><ul><ul><ul><li>Пълен текст на статията като HTML: http://localhost:3000/svi/posts/ [id ] </li></ul></ul></ul><ul><li>Възможности: </li></ul><ul><ul><li>Добавяне, редактиране, изтриване на статия </li></ul></ul><ul><ul><li>Извличане на списък статии като HTML </li></ul></ul>
    12. 12. Демонстрация
    13. 13. POST: добавяне на нов ресурс <ul><li>Може да се изпълни с всеки браузър с подходяща HTML страница </li></ul><ul><li>Съдържанието на ресурса може да бъда предадено чрез: </li></ul><ul><ul><li>application/x-www-form-urlencoded POST /svi/posts HTTP/1.0 Host: localhost:3000 Content-Type: application/x-www-form-urlencoded Content-Length: 65 title=Breaking%20News&content=Global%20Warming%20is%20not%20Myth </li></ul></ul><ul><ul><li>multipart/form-data </li></ul></ul>
    14. 14. POST: добавяне на нов ресурс <ul><li>Резултата от изпълнението е HTTP статус код </li></ul><ul><li>Сървъра връща в заглавната част на отговора полето „Location:“ указващо URI на новосъздадения ресурс HTTP/1.1 201 Created Date: Wed, 27 Jun 2007 23:26:23 GMT Location: http://localhost:3000/svi/posts/1 </li></ul>
    15. 15. GET: извличане <ul><li>Може да се изпълни с всеки браузър GET /svi/posts/1 HTTP/1.0 </li></ul><ul><li>Достатъчно е да се знае URI на ресурса </li></ul><ul><li>Как се определя кое представяне на ресурса да се предостави? </li></ul><ul><ul><li>в зависимост от URI (за предпочитане): http://localhost:3000/posts/plain-text </li></ul></ul><ul><ul><li>в зависимост от заглавната част на браузъра (content negotioation) Accept: text/xml, application/xml, text/html; q=0.9, text/plain; q=0.8, image/png, */*; q=0.5 </li></ul></ul>
    16. 16. PUT: редактиране <ul><li>Същия формат като POST </li></ul><ul><li>Не може да се направи с <form ...> </li></ul><ul><ul><li>Може да се използва в XMLHttpRequest: var httpRequest = new XMLHttpRequest(); httpRequest.open('PUT', '/svi/posts/1', true); </li></ul></ul><ul><li>Резултата от изпълнение е HTTP статус код PUT /svi/posts/1 HTTP/1.0 Host: localhost:3000 Content-Type: application/x-www-form-urlencoded Content-Length: 95 title=Old%20News%20It%20is%20already%20happening%20&content=Global%20Warming%20is%20not%20Myth </li></ul>
    17. 17. PUT vs. POST. Fight! <ul><li>Защо не се използва PUT за добавяне? </li></ul><ul><ul><li>Ако предварително е известено URI на ресурса, който ще се добавя – то PUT може да се използва за създаване </li></ul></ul><ul><ul><li>В противен случай сървъра ще генерира URI в Location полето на отговора на заявката </li></ul></ul>
    18. 18. DELETE: изтриване <ul><li>Отново не може да се направи с <form ...> </li></ul><ul><ul><li>Отново може да се използва в XMLHttpRequest: var httpRequest = new XMLHttpRequest(); httpRequest.open('DELETE', '/svi/posts/1', true); </li></ul></ul><ul><li>Резултата от изпълнение е HTTP статус код DELETE /svi/posts/1 HTTP/1.0 </li></ul>
    19. 19. Обобщение на компонентите на REST <ul><li>Ресурсът е единицата в системата, която искаме и има смисъл да се направи достъпна за други приложения </li></ul><ul><li>Всеки ресурс се идентифицира с URI </li></ul><ul><li>Ресурсите могат да имат няколко представяния </li></ul><ul><li>Ресурсите се манипулират през унифициран интерфейс (GET/DELETE/PUT и т.н.) </li></ul>
    20. 20. Какво още предлага REST <ul><li>Услугата не трябва да зависи от предишни заявки на клиента </li></ul><ul><ul><li>необходимата информация трябва да бъде в заявката (напр. GET параметри) </li></ul></ul><ul><ul><li>не винаги е възможно да се приложи на практика </li></ul></ul><ul><ul><li>Защо? Мащабируемост! </li></ul></ul><ul><ul><ul><li>Тъй като цялата информация за обработването на заявката е в самата заявка, няма значение кой сървър от група сървъри ще изпълни заявката. </li></ul></ul></ul><ul><ul><ul><li>Състоянието от предишни заявки не е необходимо да се споделя от всички сървъри </li></ul></ul></ul>
    21. 21. Какво още предлага REST <ul><li>Поощряват се връзки към други ресурси в текущото представяне на даден ресурс </li></ul><ul><ul><li>Не е необходимо да минеш през определен път за да получиш конкретно представяне на ресурс след като веднъж си стигнал до него </li></ul></ul><ul><ul><li>Защо? Оптимизация! </li></ul></ul><ul><ul><ul><li>Веднъж открити ресурсите, информацията къде се намират може да се съхрани (cache) и да се използва повторно </li></ul></ul></ul>
    22. 22. Какво още предлага REST <ul><li>Без странични ефекти </li></ul><ul><ul><li>GET/HEAD </li></ul></ul><ul><ul><ul><li>не трябва да променят състоянието на ресурсите, независимо колко пъти са изпълнени (safety) </li></ul></ul></ul><ul><ul><li>PUT/DELETE </li></ul></ul><ul><ul><ul><li>след първото изпълнение, всяко следващо не трябва да променя ресурс на сървъра (idempotence) </li></ul></ul></ul><ul><ul><li>POST </li></ul></ul><ul><ul><ul><li>трудно постижимо поведение като при PUT/DELETE (но не невъзможно) </li></ul></ul></ul><ul><ul><li>Защо? Надеждност! </li></ul></ul><ul><ul><ul><li>„Ако не стане първия път, пробвай пак“ </li></ul></ul></ul>
    23. 23. Какво още предлага REST <ul><li>Достатъчни ли са 5-6 метода за манипулиране? </li></ul><ul><ul><li>Не се поощрява измисляне на нови методи, защото интерфейса престава да бъде унифициран </li></ul></ul><ul><ul><li>Потребителите на услугата ще са свикнали с определен подход (GET - извлича, POST – създава, т.н.) </li></ul></ul><ul><ul><li>Лесно се следи и филтрира използване (и/или злоупотребата) с услугата </li></ul></ul>
    24. 24. С кои помощни проекти може да се реализира REST <ul><li>REST може да се реализира на поризволен език или framework </li></ul><ul><li>Restlet (Java) </li></ul><ul><ul><li>на път е JSR 311: Java API for RESTful Web Services </li></ul></ul><ul><li>Ruby On Rails (Ruby) </li></ul><ul><li>Django (Python) </li></ul><ul><li>Catalyst (Perl) </li></ul>
    25. 25. Благодаря за вниманието! Въпроси, коментари?

    ×