Побудова веб служб через програму REST

Original article: http://www.xfront.com/REST-Web-Services.html

Побудова веб служб через програму REST Роджер Л. Костельо
Спочатку я хотів би зробити короткий вступ до REST і потім описати побудову веб служб у стилі REST.

Що таке REST?
REST – це термін, який вжив Рой Філдінг у своїй дисертації [1] для опису архітектурного стилю мережевих систем. REST – це акронім від слова Representational State Transfer (це стиль архітектури програмного забезпечення)

Чому воно має назву Representational State Transfer?
Веб складається з ресурсів. Ресурс визначається як будь-який предмет інтересу. Наприклад, the Boeing Aircraft Corp може визначити ресурс 747. Клієнти можуть отримати доступ до цього ресурсу за URL:
http://www.boeing.com/aircraft/747
Репрезентація ресурсу має механізм повернення (наприклад, Boeing747.html). Репрезентація поміщає клієнтський додаток в стан. Результат клієнта, що проходить гіперпосилання в Boeing747.html це вже інший досягнений ресурс. Нова репрезентація поміщає клієнтський додаток в інший стан. Таким чином, зміни клієнтського додатку (трансферів) становить кожне подання ресурсів -> що і є Representational State Transfer!

Ось як пояснює Рой Філдінг значення Representational State Transfer:
«Representational State Transfer направлене на представлення того, як функціонує добре розроблена веб аплікація: мережа веб-сторінок (віртуальна машина стану), де користувач досягає прогресу через аплікацію шляхом відбору посилань (переносу станів), що потім переходить до іншої сторінки (яка представляє наступний стан аплікації) і потім доходить до користувача, який може розпочинати користування.»

Мотивація RESTy
Мотивація RESTy була спрямована на фіксування основних характеристик мережі, що зробили її успішною. Поступово ці характеристики використовувалися для про слідження етапу еволюції мережі.

REST – це архітектурний стиль, а не стандарт
REST не є стандартом. Ви не побачите як система W3C описує специфікації для RESTу. Ви також не побачите як IBM або Microsoft або Sun розпродує набір інструментів для розробки компанії REST. Чому так відбувається? Все тому що, REST – це лишень архітектурний стиль. А стилі не можна змішувати. Його можна лише зрозуміти і розроблювати дизайн для своїх веб служб у цьому стилі. (це аналог архітектурного стилю клієнт-сервер. Неможливо знайти стандарт клієнт-сервер.)
Хоча REST не є стандартом, але використовує стандарти:
• HTTP
• URL
• XML/HTML/GIF/JPEG/etc (Resource Representations)
• text/xml, text/html, image/gif, image/jpeg, etc (MIME Types)

Класична система REST
Веб – це система REST! Всі ті веб служби, якими ви користувалися всі ці роки – служби замовлення книг, служби пошуку, служби онлайн словників тощо – всі вони базуються на стилі REST. Насправді, ви користувалися RESTом, будували служби REST і навіть не знали цього.
REST визначають як «велику картину» мережі. Це ніяк не пов’язано із детальною інформацією про використання (наприклад, використання Java servlets для того, що запустити веб службу). Отже, розглянемо приклад створення веб служби з точки зорy перспективи «великої картини» від REST. Веб служби Parts Depot
Parts Depot, Inc (фіктивна компанія) застосувала деякі веб служби для того, щоб дати можливість клієнтам:
• отримати список деталей
• отримати детальну інформацію про якусь певну деталь
• зробити замовлення (РО)
Давайте розглянемо, як кожна з цих послуг здійснюються за допомогою REST.

Отримати список деталей
Веб служба дає доступ URL до ресурсу зі списком деталей. Наприклад, клієнт буде використовувати цей URL, щоб отримати список деталей:
http://www.parts-depot.com/parts
Зверніть увагу, "як" веб служба генерує список деталей, що цей список є повністю прозорим для клієнта. Всі клієнти знають, що якщо він / вона вводить URL, який вказаний вище, то документ, що містить список деталей знову повертається. Оскільки реалізація є прозорою для клієнтів, Parts Depot без перешкод може змінювати основну реалізацію цього ресурсу, і при цьому аж ніяк не шкодячи клієнтам. Це має назву слабкий зв'язок.

Ось документ, який отримує клієнт:

<?xml version="1.0"?>
<p:Parts xmlns:p="http://www.parts-depot.com" 
         xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>
      <Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/>
      <Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/>
      <Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/>
</p:Parts>

[Припустимо, що шляхом переговорів служба встановила, що клієнт хоче отримати репрезентацію від XML (для міжкомп’ютерної обробки).] Зверніть увагу, що список деталей має посилання, щоб отримати детальну інформацію про кожну деталь. Це є ключовою особливістю RESTу. Клієнт переходить з одного стану в інший шляхом вивчення і вибору альтернативних URL у відповідному документі.

Отримати детальну інформацію про якусь певну деталь
Веб служба робить доступним URL для кожної частини ресурсу. Наприклад, ось як клієнт робить запит для отримання інформації щодо деталі під номером 00345:
http://www.parts-depot.com/parts/00345
І ось який документ отримує клієнт у відповідь:

<?xml version="1.0"?>
<p:Part xmlns:p="http://www.parts-depot.com"   
        xmlns:xlink="http://www.w3.org/1999/xlink">
      <Part-ID>00345</Part-ID>
      <Name>Widget-A</Name>
      <Description>This part is used within the frap assembly</Description>
      <Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/>
      <UnitCost currency="USD">0.10</UnitCost>
      <Quantity>10</Quantity>
</p:Part>

Знову подивіться, як ці дані пов'язані з ще більшою базою даних, специфікацію якої можна знайти шляхом обходу гіперпосилання. Кожен документ відповіді дозволяє клієнту прогорнути сторінку вниз, щоб отримати більш детальну інформацію.

Зробити замовлення (РО)
Веб служба дає можливість зробити замовлення (PO) через URL. Клієнт створює екземпляр документа PO, яка відповідає схемі РО, розробленою Parts Depot (і опублікованою у документі WSDL). Клієнт вносить po.xml дані в якості корисного навантаження на HTTP POST.
РО служба реагує на HTTP POST з URL в раніше замовленому РО. Таким чином, клієнт може отримати своє замовлення в будь-який час (можна також поновити / редагувати своє замовлення). РО замовлення став інформацією, яка розповсюджується між клієнтом і сервером. Загальна інформація (РО) надається адресу (URL) на сервері і виступає в ролі веб служби.

Логічні URL проти фізичних URL
Ресурс являє собою концептуальну сутність. Репрезентація – це конкретний прояв ресурсу. Ця URL-адреса:
http://www.parts-depot.com/parts/00345
є логічною URL адресою, а не фізичною. Таким чином, можна не використовувати, наприклад, статичну сторінку HTML для кожної окремо взятої деталі. Насправді, якщо б там було цілий мільйон деталей, тоді б мільйон статичних сторінок HTML вже не мали б такий привабливий дизайн. [Детальна інформація щодо застосування: Parts Depot може реалізувати сервіс, який отримує докладні дані щодо конкретної деталі шляхом використання Java Servlet, який аналізує рядок після імені хоста, використовує номер деталі для запиту бази даних частин, формулює результати запиту у вигляді XML, а потім повертає XML вже як корисне навантаження на відповідь HTTP.]
Щодо стилю, URL не повинні розкривати техніку реалізації, яка використовується. Ви ніщо непотрібно перешкоджати, аби змінити вашу реалізацію, так щоб не вплинути негативно на клієнтів або мати невірні URL адреса.

Характеристики веб служб REST
До характеристик REST входить:
Клієнт-сервер: висувний стиль взаємодії: споживчі компоненти витісняють репрезентації.
Не має фіксування стану: кожен запит від клієнта до сервера повинен містити всю інформацію, необхідну для розуміння запиту, і не може скористатися перевагою будь-якого контексту на сервері.
Кеш: для того, що поліпшити ефективність відповідей в мережі кеш має бути спроможним поставити відмітку кешувального або НЕ кешувального файлу.
Єдиний інтерфейс: всі ресурси доступні із загальним інтерфейсом (наприклад, HTTP GET, POST, PUT, DELETE).
Названі ресурси - система складається з ресурсів, які отримують назви за допомогою URL.
Взаємопов'язані репрезентації ресурсу – репрезентація ресурсів взаємопов’язані між собою завдяки URL-адресам, що дозволяє клієнту прогресувати від одного стану до іншого.
Багатошарові компоненти – це посередники, такі як проксі-сервери, сервери кешування, шлюзи і т.д., які можуть бути вставлені між клієнтами і ресурсами для підтримки продуктивності, безпеки і т.д.

Принципи дизайну веб служб REST
1. Ключ до створення веб-служб в мережі REST (тобто, Web) полягає у визначенні всіх концептуальних об'єктів, які ви хочете бачити у ролі служб. Раніше ми вже бачили деякі приклади ресурсів: список деталей, докладні дані деталей, замовлення на придбання.

2. Створити URL для кожного ресурсу. Ресурси повинні бути іменниками, як частина мови, а не дієсловами. Наприклад, не можна використовувати наступне:
http://www.parts-depot.com/parts/getPart?id=00345
Зауважте, що у даному прикладі використовується дієслово getPart. Замість дієслова вживайте іменник:
http://www.parts-depot.com/parts/00345

3. Класифікуйте ваші ресурси в залежності від того, чи можуть клієнти просто отримати репрезентацію ресурсу, або чи може клієнти змінити (додати в обране) ресурс. Щодо першого випадку, зробіть так, щоб ці ресурси були доступними при використанні HTTP GET. У другому випадку, зробіть так, щоб ці ресурси були доступні при використанні HTTP POST, PUT, та / або DELETE.

4. Всі ресурси, доступні через HTTP GET повинні бути безкоштовними. Тобто, ресурс повинен просто повертає репрезентацію ресурсу. Посилання запиту на ресурс не повинно призводити до модифікації ресурсу.

5. Жодна людина / жінка не є островом. Точно так само, репрезентація не повинна бути островом. Іншими словами, поставте гіперпосилання в репрезентації ресурсів, щоб клієнти могли прогорнути вниз для отримання додаткової інформації та / або для отримання відповідної інформації.

6. Проведіть дизайн для виявлення даних поступово. Не відкривайте всю отриману відповідь в одному документі. Забезпечте гіперпосилання для того, щоб отримати більш детальну інформацію.

7. Вкажіть формат даних відгуку з використанням схеми (DTD, W3C Schema, RelaxNG або Schematron). Для тих послуг, які вимагають POST або PUT до нього також необхідно надати схему для того, щоб вказати формат відповіді.

8. Опишіть, як ваші послуги будуть запитуватися з використанням документу WSDL, або просто HTML документу.

Підсумки
В цій статті REST постає в якості архітектурного стилю. Насправді, це архітектурний стиль мережі. REST описує ті моменти, що роблять мережу досконалішою. Дотримуючись принципів RESTу зроблять ваші служби більш продуктивними в мережі веб.
У наступній статті я напишу про еволюцію мережі з використанням принципів REST.

Визнання
Окрема подяка Роберту Лефтвічу та Філіпу Ескеліну за їхні корисні коментарі, які були внесені при написанні даної статті.
Посилання
[1] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Home | SEO Words | Coloring