А ваша служба є RESTful? Все що необхідно/обов'язково знати про веб служби та REST

Введення
От не люблю я винаходити велосипед і статтю я б не написав, але довелося. Про REST сказано вже досить багато. Багато постачальники веб служб готові клястися, що їх служби є RESTful. Під час співбесіди ви точно почуєте хоча б декілька питань про REST, незалежно від того це співбесіди для бекенд, мобайл або фронтенд розробника. Я от пам'ятаю якось під час одного співбесіди мене поставили таке запитання: «Ось ви написали в своєму резюме, що знайте REST․ Скажіть будь ласка, якою HTTP код ви отримаєте, якщо при запиті до RESTful сервісу ресурс не знайдено?». Відповідь 404 був прийнятий одноголосно. Якщо чесно, я так і не зрозумів, як це питання допоміг зрозуміти знаю я REST чи ні, але одне можу впевнено сказати: REST розуміють далеко не всі. Ось деякі питання, які мучили мене довгий час:

  1. Навіщо REST став таким трендовим? Це архітектура була ж запропонована ще в 2000 році?
  2. Що я отримаю якщо моя служба буде RESTful?
  3. Як визначити чи є служба RESTful чи ні?
  4. Як правильно повинні створюватися URL REST служб?
  5. http Які методи і коди повинні бути використані в RESTful службі?
Якщо ви не можете дати вичерпної відповіді хоча б на одне з цих питань, то продовжуйте читання. Якщо ви можете однозначно відповісти на всі ці питання, можете привести формат правильного URL, вважайте, що GET, POST, PUT, DELETE обов'язково повинні відповідати CRUD операцій з ресурсами, то вам обов'язково треба продовжувати читання.

Щоб знайти відповіді на наведені питання і представити загальну картину довелося прочитати купу специфікацій, дисертацію Роя Філдінга і книгу Леонарда Річардсона, оскільки виявилося, що є велика плутанина в інтернеті, і зокрема в Stack Overflow. Знайдена інформацію здалося мені досить корисною ось і вирішив їм з вами поділитися.

Оскільки REST ми розглядаємо з точки зору веб служб, у статті я спробував викласти все те, що потрібно знати для уявлення загальної картини.

Ну що ж, почнемо подорож у світ веб-сервісів.

SOA & Web Services
SOA, розширювана як сервіс-орієнтована архітектура (Service Oriented Architecture), є парадигмою для організації та використання розподілених систем, які можуть перебувати під контролем різних областей власності [1]. В SOA, під service розуміється функціональна можливість, яка задовольняє наступним критеріям [2]։

  1. Представляє собою функціональність з конкретним результатом.
  2. Є самодостатнім (self-contained).
  3. Є чорним ящиком для клієнтів.
  4. Може складатися з інших послуг.
Service Description – це інформація про сервіс, необхідна для взаємодії зі службою (пр. WSDL).
Service Provider – це люди або організації, які надають сервіси.
Service Consumer – це клієнти, споживачі служб.

Web Service, згідно з визначенням [3], є системою, що призначена для взаємодії машин/програм по мережі. Веб-сервіс повинен мати інтерфейс, описаної в машинно-оброблюваному форматі (service description). Інші системи повинні взаємодіяти з веб-сервісом за допомогою повідомлень.

Взаємозв'язок між веб-сервісом і SOA є те, що SOA може бути реалізований за допомогою веб-сервісів.

Якщо вас зацікавить які ще методи існують або існували для реалізації SOA, можете подивитися COM і CORBA.

Протоколи веб служб
До того, як вирішити яка служба є RESTful, а яка ні, розглянемо деякі реалізації, або як по-іншому їх називають, протоколи веб служб. Список загальновідомих протоколів веб служб можна знайти в [4].

1. XML-RPC

Протокол XML-RPC (XML Remote Procedure Call) [5] був у перші опублікований в 1999 році. Всі повідомлення XML-RPC є HTTP-POST запитами. Для шифрування повідомлення використовується XML. Параметри процедури можуть бути скалярні значення, числа, рядки, дати, масиви і структури. Відповідь веб служби може зберігати значення, що повертається процедурою, або код і повідомлення помилки.

Приклад запиту та відповіді (приклад наведено з самої специфікації [5]):
Host: betty.userland.com
Content-Type: text/xml
Content-length: 181
<?xml version="1.0"?>
<methodCall>
<methodName>examples.getStateName</methodName>
<params>
<param>
<value><i4>41</i4></value>
</param>
</params>
</methodCall>

HTTP/1.1 200 OK
Connection: close
Content-Length: 158
Content-Type: text/xml
Date: Fri, 17 Jul 1998 19:55:08 GMT
Server: UserLand Frontier/5.1.2-WinNT
<?xml version="1.0"?>
<methodResponse>
<params>
<param>
<value><string>South Dakota</string></value>
</param>
</params>
</methodResponse>


В якості недоліку протоколу XML-RPC, наводиться великий розмір повідомлень (4 рази більше, порівняно з звичайним XML) і не існування мови опису веб-сервісу (щось схоже на WSDL), який міг був би використовуватися для генерації проксі класів на стороні клієнта.

2. JSON-RPC

Протокол JSON-RPC [6], опублікований в 2009 році, за своїми принципами роботи дуже схожий на XML-RPC. Головними відмінностями є спосіб шифрування даних, незалежність від транспортного рівня, здатність передачі повідомлень (notification request) та можливість ідентифікації відповідей при відправленні декількох запитів одночасно.

Для шифрування даних JSON-RPC використовується JSON. Крім імені процедури і параметрів, у запиті зазначається також значення id, який використовується для ідентифікації відповіді на стороні клієнта. Іншими словами, якщо ви відправили запит з id=12345, то відповідь цього запиту обов'язково повинен повертати повідомлення з id=12345.

Повідомлення – це спеціальні запити, на які сервер може не відповідати. Для оцінки запиту, як повідомлення, значення параметра id вказується = null.

Незалежність від транспортного рівня можна зумовити тільки тим, що в специфікації JSON-RPC [6] HTTP не вказується обов'язковим протоколом. При використанні JSON-RPC над HTTP, необхідно використовувати POST запити.

Приклад JSON-RPC запиту і відповіді:
--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}

--> {"jsonrpc": "2.0", "method": "subtract", "params": {"subtrahend": 23, "minuend": 42}, "id": 3}
<-- {"jsonrpc": "2.0", "result": 19, "id": 3}


Недоліком JSON-RPC, як і у випадку XML-RPC є відсутність мови опису веб-сервісу (аналог WSDL).

3. SOAP

Протокол SOAP (Simple Object Access Protocol) [7] є спадкоємцем XML-RPC. Основними характеристиками SOAP є:

  1. Всі передані повідомлення шифруються за допомогою XML (SOAP messages).
  2. Всі SOAP служби мають опис мовою WSDL, яке теж є XML-му. Це дозволяє клієнтом автоматично згенерувати проксі класи.
  3. SOAP підтримує майже всі відомі протоколи TCP/IP (TCP, UDP, HTTP, SMTP, FTP і т. д.). Саме з цієї причини SOAP є досить складним протоколом порівняно з попередніми.
  4. При використанні HTTP, підтримується як метод GET так і POST. GET допускається використовувати тільки для отримання даних, тобто на стороні сервера не має нічого мінятися. POST можна використовувати для всіх випадків. На практиці зазвичай використовується тільки POST.
Головним недоліком SOAP є його складність через гнучкості. Інший не менш важливим недоліком є підтримка шифрування тільки в XML.

Приклад SOAP запиту і відповіді :HTTP GET:
GET /travelcompany.example.org/reservations?code=FT35ZBQ HTTP/1.1
Host: travelcompany.example.org
Accept: text/html;q=0.5, application/soap+xml

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> 
<env:Header>
<m:reservation xmlns:m="http://travelcompany.example.org/reservation" 
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-30T16:25:00.000-05:00</m:dateAndTime>
</m:reservation>
</env:Header>
<env:Body>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:x="http://travelcompany.example.org/vocab#"
env:encodingStyle="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<x:ReservationRequest 
rdf:about="http://travelcompany.example.org/reservations?code=FT35ZBQ">
<x:passenger>Оке Jógvan Øyvind</x:passenger>
<x:outbound>
<x:TravelRequest>
<x:to>LAX</x:to>
<x:from>LGA</x:from>
<x:date>2001-12-14</x:date>
</x:TravelRequest>
</x:outbound>
<x:return>
<x:TravelRequest>
<x:to>JFK</x:to>
<x:from>LAX</x:from>
<x:date>2001-12-20</x:date>
</x:TravelRequest>
</x:return>
</x:ReservationRequest>
</rdf:RDF>
</env:Body>
</env:Envelope>

HTTP POST:
POST /Reservations HTTP/1.1
Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
<env:Header>
<t:transaction
xmlns:t="http://thirdparty.example.org/transaction"
env:encodingStyle="http://example.com/encoding"
env:mustUnderstand="true" >5</t:transaction>
</env:Header> 
<env:Body>
<m:chargeReservation
env:encodingStyle="http://www.w3.org/2003/05/soap-encoding"
xmlns:m="http://travelcompany.example.org/">
<m:reservation xmlns:m="http://travelcompany.example.org/reservation">
<m:code>FT35ZBQ</m:code>
</m:reservation>
<o:creditCard xmlns:o="http://mycompany.example.com/financial">
<n:name xmlns:n="http://mycompany.example.com/employees">
Оке Jógvan Øyvind
</n:name>
<o:number>123456789099999</o:number>
<o:expiration>2005-02</o:expiration>
</o:creditCard>
</m:chargeReservation
</env:Body>
</env:Envelope>

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn

<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
<env:Header>
...
...
</env:Header> 
<env:Body>
...
...
</env:Body>
</env:Envelope>


REST
REST є на сьогоднішній день мабуть самим популярним веб-сервіс протоколом.

Насправді REST зовсім не є протоколом і воно взагалі не нове. REST є архітектурою який був запропонований у 2000-ие роки Роєм Філдінга в його дисертації «Architectural Styles and the Design of Network-based Software Architectures» [8]. До цього REST архітектура була використана в багатьох проектах в рамках IETF і W3C. У самій дисертації ви не зумійте знайти термінів «веб служба» або SOA. REST архітектура була запропонована для правильного конструювання розподілених гіпермедіа систем, по іншим словом того, що на сьогодні називається World Wide Web. Щоб дисертацію Філдінга ви прийняли всерйоз, скажу, що Рой є архітектором HTTP 1.1, співавтором інтернет стандартів для HTTP та URI [10]. Загалом мужик він серйозний і відомий.

Щоб розподілена система вважалася сконструйованої за REST архітектурі, необхідно, щоб вона задовольняла наступним критеріям:

  1. Client-Server. Система повинна бути розділена на клієнтів і серверів.
  2. Stateless. Сервер не повинен зберігати будь-якої інформації про клієнтів. У запиті повинна зберігатися вся необхідна інформація для обробки запиту та, якщо необхідно, ідентифікації клієнта.
  3. Cache․ Кожна відповідь має бути зазначено, чи є він кэшируемым чи ні.
  4. Uniform Interface. Універсальний інтерфейс між компонентами системи.

    Для отримання універсального інтерфейсу вводяться наступні обмеження:

    • Identification of resources.

      У REST ресурсом є все те, чого можна дати ім'я. Наприклад, користувач, HTML документ, зображення, зареєстрований користувач, червона майка, голодна собака, поточна погода і т. д. Кожний ресурс в REST має бути ідентифікований за допомогою стабільного ідентифікатора, який не змінюється при зміні стану ресурсу. У нашому випадку ідентифікатором у REST є URI.

    • Manipulation of resources through representations.

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


    • Self-descriptive messages.

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

    • HATEOAS (hypermedia as the engine of application state).

      Цей пункт означає, що гіпертекст повинен бути використаний для навігації по API [9]. Зазначу, що у разі SOA, для цього використовується service description.

      Розглянемо даний пункт більш докладно.

      приклад нижче на запит отримання балансу, у відповіді вказано не тільки балансу, але і дії, які можуть бути виконані з рахунком.
      GET /account/12345 HTTP/1.1
      
      HTTP/1.1 200 OK
      <?xml version="1.0"?>
      <account>
      <account_number>12345</account_number>
      <balance currency="usd">100.00</balance>
      <link rel="deposit" href="/account/12345/deposit" />
      <link rel="withdraw" href="/account/12345/withdraw" />
      <link rel="transfer" href="/account/12345/transfer" />
      <link rel="close" href="/account/12345/close" />
      </account>
      


      Розглянемо цей же приклад при негативному балансі:
      GET /account/12345 HTTP/1.1
      
      HTTP/1.1 200 OK
      <?xml version="1.0"?>
      <account>
      <account_number>12345</account_number>
      <balance currency="usd">-25.00</balance>
      <link rel="deposit" href="/account/12345/deposit" />
      </account>
      


      Як можна побачити, у відповіді вже немає посилань на депозит і трансфер, оскільки ці дії для даного рахунку недоступні.
  5. Layered System. У REST допускається розділити систему на ієрархію шарів але з умовою, що кожен компонент може бачити компоненти тільки безпосередньо наступного шару. Наприклад, якщо ви викликайте службу PayPal, а він в свою чергу викликає службу Visa, ви про виклик служби Visa нічого не повинні знати.

  6. Code-On-Demand. У REST дозволяється завантаження і виконання коду програми на стороні клієнта.
І так, якщо розподілена система відповідає усім шести наведених пунктах, то можна сказати що вона влаштована по архітектурі REST, а така веб служба в цьому випадку називається RESTful службою.

Як ви вже помітили у цих пунктах нічого не сказано про GET, PUT, POST і DELETE запити, шифрування JSON, HTTP і т. д.

REST – це просто архітектура, він ніяк не прив'язаний до якихось протоколом.

Напевно, ви вже помітили, що у REST архітектурі немає нічого дивного й нового. Нового було в REST в 2000 році, коли веб тільки-тільки почав розвиватися. Щоб ще краще уявити REST та його значимість, уявіть, що веб – це розподілена система гіпермедіа, де кожен сайт являє собою гіпертекст.

Тоді звичайно виникає питання — а те, що ми бачимо і робимо на практиці, це що? В інтернеті можна знайти купу суперечок про те, як повинна виглядати RESTful служба і як не має. Які методи HTTP повинні використовуватися а які ні. Загалом, як вже зрозуміло, всі ці обговорення не мають теоритической основи, оскільки немає будь-якої специфікації про RESTful служби. В одному проекті можуть вирішити, що POST буде використано для створення нового запису в дурепою для оновлення, а в третин для видалення. Ці рішення ніяк не пов'язані з REST архітектурою.

REST & Richardson Maturity Model
І так, як же пов'язаний REST з веб службами? Які служби можна вважати RESTful, а які ні? Що ви отримаєте, якщо ваша служба буде задовольняти всім пунктам Філдінга? Відповім на ці питання по черзі:

  1. REST архітектура виправдала себе протягом останніх 16 років-на практиці веба. Оскільки веб-сервіси є частиною веба, багатьма компаніями/розробниками/дослідниками було вирішено і в разі веб-сервісів застосувати архітектуру REST, що дозволить поліпшити масштабованість компонентів, забезпечити безпеку, незалежне розгортання і т. д.

  2. Якщо веб служба задовольняє всім критеріям Філдінга, то його можна вважати RESTful, незалежно від того, чи використовується HTTP метод DELETE для видалення записів чи ні. Додам, що в веб часто використовуваними методами є GET і POST і якщо веб служба повинна бути максимально схожим на веб, то використовувати PUT і DELETE теж якось не правильно.

  3. Хоча Філдінг писав про веб і розподілену систем гіпертекстів, все одно скопирую частину його дисертації. За англійський звучить більш переконливо.
    REST provides a set of architectural constraints that, when applied as a whole, emphasizes scalability of component interactions, generality of interfaces, independent deployment of components and intermediary components to reduce interaction latency, enforce security, and
    encapsulate legacy systems.
Звучить звичайно все дуже круто, але треба щоб ваш веб-сервіс був сконструйований за REST або це просто тренд? Давайте розглянемо модель RMM (Richardson Maturity Model) Леонарда Річардсона.

Після аналізу декількох сотень веб-сервісів [11] було запропоновано модель RMM для оцінки якості, або як Річардсон назвав це, зрілості веб-сервісу. Модель RMM складається з 4 рівня. Якщо ваш сервіс відповідає останнього рівня, можна вважати його RESTful. Нижче я наведу приклади й малюнки з [12], які, за словами автора були перевірені Аароном Шварцем, Леонардом Річардсоном і іншими відомими особами. Всі приклади засновані на наступній історії: Я хочу записатися на прийом у лікаря. Від веб служби мені треба отримати вільні години прийому на конкретну дату і після записатися на прийом. І так, розглянемо всі ці чотири рівня на даному прикладі.

Рівень 0: Один URI, HTTP один метод.
Тут HTTP використовується тільки для взаємодії компонентів розподіленої системи. З методів використовується тільки один, наприклад POST. Як ви вже здогадалися, такими веб-сервісами є протоколи XML-RPC і SOAP.

image

Приклад: Отримання вільних годин доктора mjones на дату 2010-01-04.
POST /appointmentService HTTP/1.1
[various other headers]
<openSlotRequest date = "2010-01-04" doctor = "mjones"/>

HTTP/1.1 200 OK
[various headers]

<openSlotList>
<slot start = "1400" end = "1450">
<doctor id = "mjones"/>
</slot>
<slot start = "1600" end = "1650">
<doctor id = "mjones"/>
</slot>
</openSlotList>


Приклад: Реєстрація на прийом до лікаря mjones з 14:00 до 14:50. (тут у запиті напевно потрібно було б ще вказати дату, але оригінальний приклад не буду міняти).
POST /appointmentService HTTP/1.1
[various other headers]

<appointmentRequest>
<slot doctor = "mjones" start = "1400" end = "1450"/>
<patient id = "jsmith"/>
</appointmentRequest>

HTTP/1.1 200 OK
[various headers]

<appointment>
<slot doctor = "mjones" start = "1400" end = "1450"/>
<patient id = "jsmith"/>
</appointment>


XML використовується тут тільки для прикладу, на його місці міг бути JSON, HTML і т. д. Веб-сервіс має тільки один URL (відносний URL): /appointmentService. Запитувана функція вказується в тілі запиту.

Якщо ваш сервіс відповідає рівню 0, то він ще дитина.

Тепер розглянемо цей же приклад при роботі з веб-сервісом з рівнем 1.

Рівень 1: Кілька URI, один HTTP метод.
Служби цього рівня використовують поняття «розділяй і володарюй». У службі вводиться поняття ресурсів і для дії з конкретним ресурсом використовується URL цього ресурсу.

image

Приклад: Отримання вільних годин доктора mjones на дату 2010-01-04.
POST /doctors/mjones HTTP/1.1
[various other headers]

<openSlotRequest date = "2010-01-04"/>

HTTP/1.1 200 OK
[various headers]

<openSlotList>
<slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
<slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/>
</openSlotList>


Приклад: Реєстрація на прийом до лікаря mjones з 14:00 до 14:50.
POST /slots/1234 HTTP/1.1
[various other headers]

<appointmentRequest>
<patient id = "jsmith"/>
</appointmentRequest>

HTTP/1.1 200 OK
[various headers]

<appointment>
<slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
<patient id = "jsmith"/>
</appointment>


І так, якщо ви хочете виконати якусь дію з доктором, то треба використовувати відносний URL /doctors, а якщо ваша дія пов'язане з відвідуванням, URL /slots. Якщо порівняти службу першого рівня зі службою нульового рівня, то в останньому випадку є тільки один ресурс, і цей ресурс сама веб служба.

Якщо ваш сервіс відповідає рівню 1, то він є підлітком.

Рівень 2: Кілька URI, кожен підтримує різні HTTP методи (Правильне використання HTTP).
І так, на рівні 1 всі методи веб служби були відокремлені з допомогою ресурсів, але з ресурсом можна виконати купу дій. Щоб ці дії теж були якось логічно розділені, використовується можливість HTTP відправляти і приймати операції з різними методами: GET, HEAD, POST, PUT, DELETE, TRACE, CONECT. Наприклад, якщо метод є читанням, можна використовувати GET, якщо для створення POST або PUT․ В принципі, можна і навпаки, але оскільки HTTP ці методи мають якісь поняття та характеристики, краще, щоб ці поняття були ті ж, що і у веб службі, в іншому випадку ви можете отримати кешуючий метод створення ресурсу. Іншими словами, який метод ви будете використовувати для яких операцій, вже питання правильного використання протоколу HTTP․

image

Напевно, настав час для прикладів:

Приклад: Отримання вільних годин доктора mjones на дату 2010-01-04.
GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk

HTTP/1.1 200 OK
[various headers]

<openSlotList>
<slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
<slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/>
</openSlotList>


Приклад: Реєстрація на прийом до лікаря mjones з 14:00 до 14:50.
POST /slots/1234 HTTP/1.1
[various other headers]

<appointmentRequest>
<patient id = "jsmith"/>
</appointmentRequest>

HTTP/1.1 201 Created
Location: slots/1234/appointment
[various headers]

<appointment>
<slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
<patient id = "jsmith"/>
</appointment>


З введенням різних HTTP методів вводиться також необхідність повернення правильних HTTP статус кодів. Наприклад, на запит створення зустрічі, якщо вона створена, то повинен бути повернутий код 201. Якщо протягом ваших дій хто-то вже реєструвався на вибраний день і годину, повинен бути повернутий код 409 conflict і т. д. Знову ж таки, тут справа в правильному використанні протоколу HTTP․

Якщо ваш сервіс відповідає рівню 2, то він є вже дорослим чоловіком.

Рівень 3: HATEOAS․ Ресурси самі описують свої можливості і взаємозв'язку.
HATEOAS (Hypertext as the Engine of Application State), вимога яке, на мій погляд обов'язковий для гіпермедіа, але наскільки це актуальне для веб служб — не знаю. Все ж, HATEOAS – це характеристика веб-сервісу повертати дії у вигляді URL, які можуть бути виконані з потрібних вам ресурсом.

image

Оскільки HATEOAS було вже розглянуто вище, тут я наведу лише кілька прикладів.

Приклад: Отримання вільних годин доктора mjones на дату 2010-01-04.
GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk

HTTP/1.1 200 OK
[various headers]

<openSlotList>
<slot id = "1234" doctor = "mjones" start = "1400" end = "1450">
<link rel = "/linkrels/slot/book" 
uri = "/slots/1234"/>
</slot>
<slot id = "5678" doctor = "mjones" start = "1600" end = "1650">
<link rel = "/linkrels/slot/book" 
uri = "/slots/5678"/>
</slot>
</openSlotList>


Кожен вільний час має URL, для виконання дій над ним, у цьому випадку реєстрація на цю годину.

Приклад: Реєстрація на прийом до лікаря mjones з 14:00 до 14:50.
POST /slots/1234 HTTP/1.1
[various other headers]

<appointmentRequest>
<patient id = "jsmith"/>
</appointmentRequest>

HTTP/1.1 201 Created
Location: http://royalhope.nhs.uk/slots/1234/appointment
[various headers]

<appointment>
<slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
<patient id = "jsmith"/>
<link rel = "/linkrels/appointment/cancel"
uri = "/slots/1234/appointment"/>
<link rel = "/linkrels/appointment/addTest"
uri = "/slots/1234/appointment/tests"/>
<link rel = "self"
uri = "/slots/1234/appointment"/>
<link rel = "/linkrels/appointment/changeTime"
uri = "/doctors/mjones/slots?date=20100104@status=open"/>
<link rel = "/linkrels/appointment/updateContactInfo"
uri = "/patients/jsmith/contactInfo"/>
<link rel = "/linkrels/help"
uri = "/help/appointment"/>
</appointment>


Перевагою HATEOAS є те, що воно дає можливість розробникам веб служб міняти URI незалежно від клієнтів. Крім цього, веб-сервіс сам описує себе без будь-яких WSDL. Щоб правильно уявити HATEOAS, уявіть веб-сайту з статичних сторінок. Ви відкривайте головну сторінку, а там уже посилання на все інше. Щоб зайти на веб-сайт і щось знайти там, немає необхідності прочитати якийсь документ з даного сайту, щось на зразок документа по API. Знову ж таки, моя суб'єктивна думка щодо необхідності веб-сервісу підтримувати HATEOAS досить песимістично.

Якщо ваш сервіс відповідає рівню 3, то його можна вже називати RESTful ну і звичайно старим з хорошим оптом.

Висновок
Якщо ви читайте ці рядки означає або прочитали всю статтю і дійшли до висновку, або з причини браку часу перегорнули основну статтю читайте тільки висновок.

Оскільки другий випадок більш поширений ніж перший, наведу основні концепції:

  1. Веб-сервіс – це один з методів реалізації SOA.
  2. Веб-сервіс протоколом називається конкретна реалізації веб-сервісу (XML-RPC, SOAP, JSON-RPC, і т. д.).
  3. REST є архітектурою, який був запропонований у 2000 році і застосовувався для правильного створення компонентів веба і розподілених гіпермедіа систем в цілому.
  4. Питання чим відрізняється SOAP від REST, майже те ж саме, що запитати, чим відрізняється бізон від хижака. SOAP-це протокол, у якого є специфікація, а REST – це архітектура, яку можна застосувати для створення веб-служб з використанням HTTP і URL.
  5. Richardson Maturity Model – це модель, запропонований Леонардом Річардсоном для оцінки зрілості веб служби. Поняття «дитина», «підліток», «чоловік» і «старий» я сам ввів, щоб добре уявити шару моделі RMM.
Чи веб служба дитиною або старим – ваш вибір. Якщо ви або ваша компанія розробляйте і серверну частину програми та клієнтську, то думаю немає необхідності, щоб ваша служба задовольняла всім пунктам RMM, особливо HATEOAS. «Чоловік» або «підліток» з цим завданням легко впораються. А якщо ви розробляйте щось на зразок amazon, у вас повинні бути кілька тисяч клієнтів, про яких ви поняття не майте, то з цим напевно найкращим чином впоратися «старий». Якщо ж ваша служба має дуже мало функцій, то дайте цю роботу «дитині», він знає, як усі злити в одну купу (в один ресурс).

Література
1. www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf
2. www.opengroup.org/standards/soa
3. www.w3.org/TR/ws-arch/#whatis
4. en.wikipedia.org/wiki/List_of_web_service_protocols
5. xmlrpc.scripting.com/spec.html
6. www.jsonrpc.org/specification
7. www.w3.org/TR/soap
8. www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf
9. restcookbook.com/Basics/hateoas
10. roy.gbiv.com/untangled/about
11. www.crummy.com/writing/speaking/2008-QCon/act3.html
12. martinfowler.com/articles/richardsonMaturityModel.html
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.