RESTful Architechture (Highload++ 2008)
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

RESTful Architechture (Highload++ 2008)

  • 852 views
Uploaded on

RESTful архитектура для масштабируемых систем

RESTful архитектура для масштабируемых систем

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
852
On Slideshare
852
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
12
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. RESTful архитектура для масштабируемых систем Сергей Скворцов $Revision:: 30 $ 2008-10-06
  • 2. Содержание
    • REST – введение
    • REST – масштабируемость
    • REST – нюансы и тонкости
  • 3. I . REST – что это?
  • 4. Re presentational S tate T ransfer
    • REST – это архитектурный стиль
    • Ключевые понятия:
      • Ресурс - Resource
      • Представление - Representation
      • Состояние - State
      • Перенос состояния – Transfer
  • 5. REST: история
    • Roy Fielding - один из авторов HTTP
    • « Designing the Web Architecture: Problems and Insights » - его докторская диссертация
      • Стоит прочесть!
    • REST есть post hoc описания Web как такового
    • HTTP 1.1 (RFC 2616) был обновлён под REST
  • 6. REST: стиль
    • Identifiable resources
    • Uniform interface
    • Stateless – отсутствие (application) состояния на сервере
    • Cached – кэширование
    • Layers – разделение на уровни
  • 7. Вот это НЕ REST :
    • Remote Procedure Call ( RPC)
      • XML-RPC, JSON-RPC
      • SOAP: WS-*, WSDL, …
    • Stateful системы / протоколы
      • Пример: FTP
    • Message passing / Instant Messaging
  • 8. Web Service s – два мира
    • Programmable Web : клиенты это программы
      • API - Web Service Protocols
      • Ресурсы – machine-readable
    • Human Web : клиенты это люди
      • Сайт - Web Application
      • Ресурсы – human-readable
    • REST используется в обоих типах WS
    • RPC – только для Programmable Web
  • 9. Resource is…
    • Ресурс– это объект высшего порядка
      • Объект , сущность – частные случаи ресурса
    • Ресурс – это суть, концепция , представление - его форма
    • Значение ресурса – его состояние (содержание)
    • Ресурс можно увидеть и изменить только через его представление ( HTML, XML, PDF,… )
  • 10. Resource - термины
    • Ресурс – это концепция
    • URI – идентификатор ресурса
      • Т.е. уникальный и URIs сравниваемые между собой
      • У одного ресурса может быть несколько URIs
    • Представление – HTML, XML, PNG, …
    • Метаданные представления – media type, last-modified time, …
  • 11. State is…
    • Resource State
      • это значение ресурса
    • Application State
      • Это состояние сессии
      • В REST сессии хранятся только на клиенте
      • Hypertext – это application state engine
  • 12. State и Transfer в RE ST
    • Это Application State
    • Состояние ( State ) есть часть сообщения, передаваемого ( Transfer ) от сервера к клиента, и обратно к серверу
    • Т.о. любой сервер, получив состояние, может продолжить транзакцию с верной точки
  • 13. REST: дизайн
    • Фиксированное число глаголов
      • Методы : POST, GET, PUT, DELETE; HEAD
      • CRUD : Create, Retrieve, Update, Delete
      • SQL : INSERT, SELECT, UPDATE, DELETE
    • Бесконечное число существительных
      • Ресурсы , ресурсы , ресурсы!
  • 14. Примеры ресурсов
    • Ресурс для объекта
      • /papers/ HL2008-RESTful-Architechture.ppt
    • Ресурс как запрос
      • /orders/by-state/open
      • /search?q=HighLoad
    • Ресурс как алгоритмический запрос
      • /prime-numbers?from=37&size=5
  • 15. Пример операций
    • Список пользователей :
      • GET /users
    • Создать пользователя :
      • POST /users
    • Получить данные о пользователе :
      • GET /users/ [ID]
    • PUT, DELETE, …
  • 16. REST vs. SOAP POST /generic_message_handler C ontent-type : application/SOAP+XML <soap:envelope> <soap:body> <submit-purchase-order> <destination> accounting.mycompany.com </destination> <po>...</po> </submit-purchase-order> </soap:body> <soap:envelope> Это сокращённый вариант!
  • 17. REST vs. SOAP POST /purchase_orders HTTP/1.1 Host: accounting.mycompany.com C ontent-type: application/purchase-order+xml <po>...</po> Всё!
  • 18. REST vs. WS-*
    • SOAP WS-*
      • Сложно !
      • Повторение истории CORBA
    • REST – это просто !
    • HTTP – вечен!
  • 19. Протокол HTTP
    • Это протокол уровня приложений ( application)
      • REST
    • … а не транспортный протокол
      • Как его трактует SOAP
  • 20. Примеры REST API
    • HTTP ( да-да!)
    • Atom Application Protocol (APP, RFC 5023 )
      • OpenSearch, GData
    • Google: Search, OpenSocial, Feeds, …
    • Amazon : eCommerce , S3 , …
    • Yahoo!: почти все API
      • Delicious, Flickr, …
    Ваше API?
  • 21. II . Масштабируемость и RESTful style
  • 22. REST: атрибуты качества
    • Готовность (Availability)
    • Производительность (Performance)
    • Модифицируемость (Modifiability)
    • Безопасность (Security)
    • Сопровождаемость (Maintainability)
    • Тестируемость ( Testability)
    • Концептуальная целостность (Conceptual integrity)
  • 23. Layers isolation
    • Логическое разделение на уровни
    • Схожий API для людей и машин
    • Общий базис в виде frameworks
  • 24. URIs вместо одной точки входа ( RPC)
    • Нет нужды анализировать тело запроса, чтобы понять что с ним делать
    • Балансируется просто по кускам URI:
      • /users/ - на backends_1
      • /orders/ - на backends_2
      • /users/ [ID] /profile – sharding на уровне [ID]
    • В URI не обязательно должен быть смысл – но это часто удобно – в виде правил именования.
      • Cool URIs don’t change!
  • 25. Web - распределёная система
    • Данные
      • Ресурсы, идентификаторы, представления
    • Компоненты (components)
      • Origin servers (ex: Apache), Gateways (ex.: Squid), Proxies (ex: firewalls), User Agents (ex: Firefox)
    • Соединители ( connectors)
      • Clients, Servers, Caches, Resolvers, Tunnels
    RFC 2616
  • 26. Кэширование
    • Кэширование на стороне клиента (в браузере, в кэше приложения)
    • Кэширование на уровне intermediaries ( прокси)
      • Полное использование архитектуры Web
    • Как итог: меньше запросов/трафика на ваши сервера
    • Надо лишь выдавать корректные HTTP- заголовки : Last-Modified; ETag; Expires; Cache-Control
  • 27. Отсутствие состояния
    • Легко достигается горизонтальная масштабируемость серверов:
      • за счёт отсутствия состояния клиента на сервере (нет session affinity)
      • Stateless – это лучший load balancing
      • Loose coupling
  • 28. III . REST – прочее
  • 29. REST и web frameworks
    • Catalyst / Perl : Catalyst-Action-REST
    • RubyOnRails – c версии 2.0
    • Python : django-rest-interface
    • Java : Restlet, Spring MVC
    • ASP.NET 2.0
    • и так далее
  • 30. Критерии хорошего REST API
    • Addressability
      • Все ресурсы и состояние клиента адресуемы
    • Statelessness
    • Connectedness
      • Ссылки на другие ресурсы – в представлении ресурсы
    • Uniform interface
      • Только стандартные HTTP методы – без расширения и сужения
  • 31. HTML 5 и REST <form id=&quot;createUser&quot; method =&quot; PUT &quot; template =&quot; /user/{username} &quot;> <label>Username:</label> <input type=&quot;text&quot; name=&quot;username&quot; /> PUT здесь – аналог REPLACE в SQL В method может быть и DELETE
  • 32. REST и AJAX
    • AJAX – это клиент/приложение для Programmable Web , запускаемое внутри браузера
    • Поэтому хороший API – особо важен (особенно кэшируемость ответов)
    • Иногда AJAX рушит addressability – этого надо избегать ( см. Gmail )
  • 33. Кошерны ли cookies ?
    • Stateful : cookie есть ссылка на сессию, которая хранится на сервере
      • Ужасно! Проблема session affinity .
    • Stateless : cookie содержит значение сессии
      • Ещё лучше, если состояние клиента определяется лишь по URI и Representation
  • 34. Нужен ли WADL ?
    • Web Application Description Language
    • CORBA – IDL
    • WS-* - WSDL
    • REST - ?? ?
      • Нет, ничего не надо!
  • 35. REST – Unix Way
    • Command line ↔ URL (arguments ↔ query string)
    • Filesystem ↔ URL
    • «Всё есть файл» ↔ «Всё есть ресурс»
    • Pipeline + tools ↔ components + intermediates
    • Набор общих, простых и стройных концепций
  • 36. Вопросы? ( по теме доклада) Сергей Скворцов skv@ protey .ru
  • 37. Библиография
    • http://www.google.ru/search?q=re st
    • http://delicious.com/search?p=rest
    • http ://en.wikipedia.org/wiki/Representational_State_Transfer
    • http://oreilly.com/catalog/9780596529260/
    • http://home.ccil.org/~cowan/restws.pdf
    • http://www.slideshare.net/dullhunk/if-web-services-are-the-answer-whats-the-question/
    • ……