REST/SOAP/gRPC
Last updated
Last updated
REST(Від англ. Representational State Transfer - "передача репрезентативного стану" або "передача "самоописуваного" стану") - архітектурний стиль взаємодії компонентів розподіленої програми в мережі. Іншими словами, REST - це набір правил того, як програмісту організувати написання коду серверного додатка, щоб усі системи легко обмінювалися даними та програму можна було масштабувати. REST є узгодженим набором обмежень, що враховуються при проектуванні розподіленої гіпермедіа-системи. У певних випадках (інтернет-магазини, пошукові системи, інші системи, засновані на даних) це призводить до підвищення продуктивності та спрощення архітектури. У широкому значенні компоненти в REST взаємодіють на кшталт взаємодії клієнтів та серверів у Всесвітньому павутинні. REST є альтернативою RPC.
У мережі Інтернет виклик віддаленої процедури може бути звичайним HTTP-запитом (зазвичай GET або POST; такий запит називають «REST-запит»), а необхідні дані передаються як параметри запиту. Для веб-служб, побудованих з урахуванням REST (тобто не порушують обмежень, що накладаються ним), застосовують термін «RESTful».
На відміну від веб-сервісів (веб-служб) на основі SOAP, немає «офіційного» стандарту для RESTful веб-API. Справа в тому, що REST є архітектурним стилем, тоді як SOAP є протоколом. Незважаючи на те, що REST не є стандартом сам по собі, більшість RESTful-реалізацій використовують такі стандарти як HTTP, URL, і, рідше, XML.
Вимоги до архітектури REST
Існує шість обов'язкових обмежень для побудови розподілених REST-додатків за Філдінгом.
Виконання цих обмежень є обов'язковим для REST-систем. Обмеження, що накладаються, визначають роботу сервера в тому, як він може обробляти і відповідати на запити клієнтів. Діючи в рамках цих обмежень, система набуває таких бажаних властивостей як продуктивність, масштабованість, простота, здатність до змін, переносимість, відстежуваність і надійність. Якщо сервіс-додаток порушує будь-яку з цих умов, цю систему не можна вважати REST-системою.
Обов'язковими умовами-обмеженнями є:
Модель клієнт-сервер : Першим обмеженням, застосовним до гібридної моделі, є приведення архітектури до моделі клієнт-сервер. Розмежування потреб є принципом, що лежить в основі даного обмеження, що накладається. Відділення потреби інтерфейсу клієнта від потреб сервера, що зберігає дані, підвищує переносимість коду клієнтського інтерфейсу інші платформи, а спрощення серверної частини покращує масштабируемость. Найбільший вплив на всесвітню павутину, мабуть, має саме розмежування, що дозволяє окремим частинам розвиватися незалежно друг від друга, підтримуючи потреби у розвитку інтернету із боку різних організацій.
Відсутність стану: Протокол взаємодії між клієнтом та сервером вимагає дотримання наступної умови: у період між запитами клієнта жодна інформація про стан клієнта на сервері не зберігається (Stateless protocol або «протокол без збереження стану»). Усі запити від клієнта мають бути складені так, щоб сервер отримав всю необхідну інформацію для виконання запиту. Стан сесії у своїй зберігається за клієнта. Інформація про стан сесії може бути передана сервером будь-якому іншому сервісу (наприклад, службу бази даних) для підтримки стійкого стану, наприклад, на період встановлення аутентифікації. Клієнт ініціює надсилання запитів, коли він готовий (виникає необхідність) перейти в новий стан. Під час обробки запитів клієнтів вважається, що клієнт перебуває в перехідному стані.
Кешування : Інформація повинна бути перевірена, інакше її можна видалити. Ви можете редагувати статтю, додавши посилання на авторитетні джерела. Ця позначка встановлена 16 березня 2017 року. Як і у Всесвітньому павутинні, клієнти, а також проміжні вузли можуть виконувати кешування відповідей сервера. Відповіді сервера, у свою чергу, повинні мати явне або неявне позначення як кешовані або некешовані з метою запобігання одержанню клієнтами застарілих або невірних даних у відповідь на наступні запити. Правильне використання кешування здатне частково або повністю усунути деякі клієнт-серверні взаємодії, ще більше підвищуючи продуктивність та масштабованість системи.
Наявність уніфікованого інтерфейсу є фундаментальною вимогою дизайну REST-сервісів . Уніфіковані інтерфейси дозволяють кожному із сервісів розвиватися незалежно. До уніфікованих інтерфейсів пред'являються такі чотири обмежувальні умови:
Ідентифікація ресурсів: Усі ресурси ідентифікуються у запитах, наприклад, з використанням URI в інтернет-системах. Ресурси концептуально відокремлені від уявлень, що повертаються клієнтам. Наприклад, сервер може надсилати дані з бази даних у вигляді HTML, XML або JSON, жоден з яких не є типом зберігання всередині сервера.
Маніпуляція ресурсами через подання: Якщо клієнт зберігає подання ресурсу, включаючи метадані - він має достатню інформацію для модифікації чи видалення ресурсу.
«Самоописувані» повідомлення: Кожне повідомлення містить достатньо інформації, щоб зрозуміти, як його обробляти. Наприклад, обробник повідомлення (parser), необхідний вилучення даних, може бути зазначений у списку MIME-типів.
Гіпермедіа як засіб зміни стану програми (HATEOAS): Клієнти змінюють стан системи тільки через дії, які динамічно визначені в гіпермедіа на сервері (наприклад, гіперпосилання в гіпертексті). Виключаючи прості точки входу до програми, клієнт не може припустити, що доступна якась операція над якимось ресурсом, якщо не отримав інформацію про це у попередніх запитах до сервера. Немає універсального формату для надання посилань між ресурсами, Web Linking (RFC 5988 -> RFC 8288) та JSON Hypermedia API Language є двома популярними форматами надання посилань у REST HYPERMEDIA сервісах.
Шари : Клієнт зазвичай не здатний точно визначити, взаємодіє він безпосередньо з сервером або з проміжним вузлом, у зв'язку з ієрархічною структурою мереж (маючи на увазі, що така структура утворює шари). Застосування проміжних серверів здатне підвищити масштабованість за рахунок балансування навантаження та розподіленого кешування. Проміжні вузли також можуть підпорядковуватися безпеці з метою забезпечення конфіденційності інформації.
Код на вимогу (необов'язкове обмеження): Інформація має бути перевірена, інакше її можна видалити. Ви можете редагувати статтю, додавши посилання на авторитетні джерела. Ця позначка встановлена 16 березня 2017 року. REST може дозволити розширити функціональність клієнта рахунок завантаження коду з сервера як аплетів чи скриптів. Філдинг стверджує, що додаткове обмеження дозволяє проектувати архітектуру, яка підтримує бажану функціональність у загальному випадку, але можливо, за винятком деяких контекстів.
SOAP
SOAP є розширенням протоколу XML-RPC. SOAP може використовуватися з будь-яким протоколом прикладного рівня: SMTP, FTP, HTTP, HTTPS та ін. Однак його взаємодія з кожним із цих протоколів має свої особливості, які мають бути визначені окремо. Найчастіше SOAP використовується поверх HTTP. SOAP є одним із стандартів, на яких базуються технології веб-служб.
Envelope - кореневий елемент, який визначає повідомлення та простір імен, використаний у документі;
Header - містить атрибути повідомлення, наприклад: інформація про безпеку або мережеву маршрутизацію;
Body - містить повідомлення, яким обмінюються програми;
Fault - необов'язковий елемент, який надає інформацію про помилки, що сталися під час обробки повідомлень.
Якщо Ви направите до веб-сервісу нестандартний запит, він відповість на це помилкою. WSDL - це зведення правил спілкування з вашим сервісом, дотримуючись яких ви зможете з цим сервісом комунікувати. Власне WSDL і XSD докладно описують, що і в якому вигляді надсилати на сервер, щоб отримати хорошу відповідь.
Що тестується у SOAP? Бізнес-логіка і те, що схема валідується сервером (а також те, що вона приймає на вхід параметри правильного формату). Власне все, що стосується схеми, перевіряється на етапі розробки, а потім тільки бізнес-логіка (до того моменту, поки знову не почнуться зміни в схемі).
Відмінності REST та SOAP
SOAP і REST не можна порівнювати безпосередньо, оскільки перший - це протокол (або принаймні намагається ним бути), а другий - архітектурний стиль.
Основна відмінність між SOAP та REST полягає у ступені зв'язку між реалізаціями клієнта та сервера. Клієнт SOAP працює як настільна програма користувача, тісно пов'язана з сервером. Між клієнтом та сервером існує жорстка угода, і очікується, що все зламається, якщо якась із сторін щось змінить. Вам потрібне постійне оновлення після будь-якої зміни, але легше визначити, чи виконується контракт.
SOAP більш застосовний у складних архітектурах, де взаємодія з об'єктами виходить за рамки теорії CRUD, а ось у додатках, які не залишають рамки даної теорії, цілком застосовним може виявитися саме REST через свою простоту і прозорість. Справді, якщо будь-яким об'єктам вашого сервісу не потрібні складніші взаємини, крім: «Створити», «Прочитати», «Змінити», «Видалити» (як правило - у 99% випадків цього достатньо), можливо, саме REST стане правильним вибором. Крім того, REST в порівнянні з SOAP, може виявитися і більш продуктивним, тому що не вимагає витрат на розбір складних XML команд на сервері (виконуються звичайні запити HTTP - PUT, GET, POST, DELETE). Хоча SOAP, у свою чергу, більш надійний та безпечний.
gRPC
Для тих, хто ще не чув про gRPC, gRPC - це не залежить від мови фреймворк для віддаленого виклику процедур (RPC, remote procedure calls), розроблений Google, яка серйозно вкладається у продуктивність та масштабування. Він з'явився досить давно, але багато хто (а, можливо, тільки я) відклали його на другий план через витрати на написання IDL та додаткового коду стабів (stub), який теж необхідно підтримувати. У той самий час REST дуже легко реалізується з допомогою ASP.NET Core WebAPI.
Джерела:
Дод. матеріал:
Просто подивитися як виглядають запити-відповіді можна у вкладці Network у DevTools. Спробувати надіслати запит і переглянути відповідь можна за допомогою .
SOAP (від англ. Simple Object Access Protocol - простий протокол доступу до об'єктів) - протокол обміну структурованими повідомленнями в розподіленому обчислювальному середовищі. Спочатку SOAP призначався переважно реалізації віддаленого виклику процедур (RPC). Наразі протокол використовується для обміну довільними повідомленнями у форматі , а не лише для виклику процедур. Офіційна специфікація останньої версії 1.2 протоколу не розшифровує назву SOAP.
протоколу:
- це описова мова, заснована на мові розмітки XML, і саме в wsdl описаний веб-сервіс, який вам доведеться тестувати. WSDL включає інформацію про місцезнаходження сервісу, часто включає в себе XSD. Саме з WSDL SOAPUI генерує класи, що перевіряються.
– це мова опису структури XML документа. Його також називають XML Schema. При використанні XML Schema XML пасер може перевірити не тільки правильність синтаксису XML документа, але також його структуру, модель змісту та типи даних.
Аналогічно використанню JSON для REST, для gRPC використовується - формат, що не залежить від мови, для серіалізації структурованих даних. Цим gRPC відрізняється від REST. Підтримка Protocol Buffers є всім основних мов завдяки компілятору protoc, який генерує необхідний вихідний код класів з визначень у proto-файлі. Ще важливий момент полягає в тому, що для зв'язку gRPC використовує HTTP/2, а це приносить додаткові переваги, такі як стиснення заголовків HTTP і мультиплексування запитів.