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

1. Инте REST ни уеб усуги Свилен Иванов (svilen.ivanov@gmail.com) (http://svilen-online.blogspot.com) УебТех 2007, Варна 30 юни

2. Преди да започна... С какво ще се опитам да задържа Вашето внимание: познати или непознати възможности на HTTP протокола разбираем начин за предоставяне на уеб услуги как да осигурим мащабируемост (scalability) и надеждност на приложенията как лесно да интегрираме няколко приложения

3. Какво е „уеб услуга“? Уеб услугите могат да бъдат разгледани като уеб страници предназначени за „компютри“ Приложенията-клиенти на уеб услуга биха могли да обработят („разберат“) предоставената информацията

4. Какво не е наред с уеб услугите? Изискват от разработчика да учат нови технологии: SOAP, WSDL, UDDI, WS-Security, WS-Reliability, WS-ReliableMessaging, WS-Addressing, WS-Transaction Обвързват програмиста с продукти на големи компании не се толерират реализации със свободен софтуер Сложни технологии защото трябва да решават сложни проблеми

5. Какви услуги искаме? За прости услуги споменатите технологии са прекалено голямо усилие Какви услуги могат да бъдат наречени „прости“: действия, които са достъпни за потребителя: блог – добавяне, изтриване или редактиране на статия, редактиране на коментари, търсене по ключови думи, RSS/PDF вариант на статиите фото сайт - добавяне, изтриване или редактиране на снимки, достъп до различни по размери варианти на снимката, EXIF информацията; подреждане на снимките по фото албуми

6. С какво разполагаме? Разработчиците познават (X)HTML и CSS: не се плашат от малко XML някои предпочитат JSON Запознати с HTTP протокола URI (URL) методи GET, POST заглавие на заявката: content-type, cookies XMLHttpRequest

7. Архитектура ориентирана към ресурси Ресурси самостоятелна единица информация, която има смисъл сама по себе си Примери последната написана статия в блог списък със статии написани 25 юни 2007 статии отбелязани с етикета „webtech“ статията „Уебтех във Варна“ петия коментар към статията „Уебтех във Варна“ списък с коментари за дадена статия

8. Ресурси и URIs Ресурсите могат да бъдат представени с (поне едно) URI Примери последната написана статия в блог: http://example.com/svi/posts/latest списък със статии написани 25 юни 2007: http://example.com/svi/posts/2007/06/25 статии отбелязани с етикета „webtech“c http://example.com/svi/tags/webtech

9. Ресурси и URIs Примери: Статия „Уебтех във Варна“: http://example.com/svi/webtech-in-varna Коментари към статия „Уебтех във Варна“: http://example.com/svi/webtech-in-varna/ ↵ comments петия коментар към статията http://example.com/svi/webtech-in-varna/ ↵ comments/5 статията като PDF: http://example.com/svi/webtech-in-varna/pdf

10. Манипулиране на ресурсите Изпълнение на HTTP заявка с подходящ метод „метод“ като във <form method=“post“....> GET, POST са по-известни от PUT, DELETE, HEAD, OPTIONS Видове манипулиране Извличане на ресурс: HTTP GET Създаване на нов ресурс: HTTP POST или PUT Модифициране на ресурс: HTTP PUT Изтриване на ресурс: HTTP DELETE Извличане на част от информацията: HEAD

11. Пример: опростен блог Ресурси: Основния ресурс е съвкупност от статии (post) Представяния: Списък на заглавията на всички статии като HTML http://localhost:3000/svi/posts Пълен текст на статията като HTML: http://localhost:3000/svi/posts/ [id ] Възможности: Добавяне, редактиране, изтриване на статия Извличане на списък статии като HTML

12. Демонстрация

13. POST: добавяне на нов ресурс Може да се изпълни с всеки браузър с подходяща HTML страница Съдържанието на ресурса може да бъда предадено чрез: 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 multipart/form-data

14. POST: добавяне на нов ресурс Резултата от изпълнението е HTTP статус код Сървъра връща в заглавната част на отговора полето „Location:“ указващо URI на новосъздадения ресурс HTTP/1.1 201 Created Date: Wed, 27 Jun 2007 23:26:23 GMT Location: http://localhost:3000/svi/posts/1

15. GET: извличане Може да се изпълни с всеки браузър GET /svi/posts/1 HTTP/1.0 Достатъчно е да се знае URI на ресурса Как се определя кое представяне на ресурса да се предостави? в зависимост от URI (за предпочитане): http://localhost:3000/posts/plain-text в зависимост от заглавната част на браузъра (content negotioation) Accept: text/xml, application/xml, text/html; q=0.9, text/plain; q=0.8, image/png, */*; q=0.5

16. PUT: редактиране Същия формат като POST Не може да се направи с <form ...> Може да се използва в XMLHttpRequest: var httpRequest = new XMLHttpRequest(); httpRequest.open('PUT', '/svi/posts/1', true); Резултата от изпълнение е 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

17. PUT vs. POST. Fight! Защо не се използва PUT за добавяне? Ако предварително е известено URI на ресурса, който ще се добавя – то PUT може да се използва за създаване В противен случай сървъра ще генерира URI в Location полето на отговора на заявката

18. DELETE: изтриване Отново не може да се направи с <form ...> Отново може да се използва в XMLHttpRequest: var httpRequest = new XMLHttpRequest(); httpRequest.open('DELETE', '/svi/posts/1', true); Резултата от изпълнение е HTTP статус код DELETE /svi/posts/1 HTTP/1.0

19. Обобщение на компонентите на REST Ресурсът е единицата в системата, която искаме и има смисъл да се направи достъпна за други приложения Всеки ресурс се идентифицира с URI Ресурсите могат да имат няколко представяния Ресурсите се манипулират през унифициран интерфейс (GET/DELETE/PUT и т.н.)

20. Какво още предлага REST Услугата не трябва да зависи от предишни заявки на клиента необходимата информация трябва да бъде в заявката (напр. GET параметри) не винаги е възможно да се приложи на практика Защо? Мащабируемост! Тъй като цялата информация за обработването на заявката е в самата заявка, няма значение кой сървър от група сървъри ще изпълни заявката. Състоянието от предишни заявки не е необходимо да се споделя от всички сървъри

21. Какво още предлага REST Поощряват се връзки към други ресурси в текущото представяне на даден ресурс Не е необходимо да минеш през определен път за да получиш конкретно представяне на ресурс след като веднъж си стигнал до него Защо? Оптимизация! Веднъж открити ресурсите, информацията къде се намират може да се съхрани (cache) и да се използва повторно

22. Какво още предлага REST Без странични ефекти GET/HEAD не трябва да променят състоянието на ресурсите, независимо колко пъти са изпълнени (safety) PUT/DELETE след първото изпълнение, всяко следващо не трябва да променя ресурс на сървъра (idempotence) POST трудно постижимо поведение като при PUT/DELETE (но не невъзможно) Защо? Надеждност! „Ако не стане първия път, пробвай пак“

23. Какво още предлага REST Достатъчни ли са 5-6 метода за манипулиране? Не се поощрява измисляне на нови методи, защото интерфейса престава да бъде унифициран Потребителите на услугата ще са свикнали с определен подход (GET - извлича, POST – създава, т.н.) Лесно се следи и филтрира използване (и/или злоупотребата) с услугата

24. С кои помощни проекти може да се реализира REST REST може да се реализира на поризволен език или framework Restlet (Java) на път е JSR 311: Java API for RESTful Web Services Ruby On Rails (Ruby) Django (Python) Catalyst (Perl)

25. Благодаря за вниманието! Въпроси, коментари?