Меню

Підручник з веб-служб: Компоненти, архітектура, типи та приклади

  • Головна
  • Інший
  • Підручник з веб-служб: Компоненти, архітектура, типи та приклади

web services tutorial

Спробуйте Наш Інструмент Для Усунення Проблем

Цей підручник з веб-служб пояснює архітектуру, типи та компоненти веб-служби, а також важливі термінології та відмінності між SOAP і REST:

У цьому Повна серія підручників з тестування API , ми дослідили все про Тестування API у нашому попередньому уроці. Пройдіть цей посібник, щоб ознайомитися з WSDL та UDDI, а також як вони зберігають та визначають веб-службу.

Цей підручник також пояснить, як веб-служби працюють внутрішньо, коли клієнтська програма робить запит. Тут також пояснюється WSS, що є ще однією дуже важливою концепцією SOAP Services.

Підручник з веб-служб

Що ви дізнаєтесь:

Важливі термінології у тестуванні веб-служб

Перш ніж ми почнемо вивчати веб-служби, ми повинні бути ознайомлені з важливими термінами, які використовуються в тестуванні веб-служб.

Давайте розпочнемо!!

# 1) Сумісність

Підтримка веб-служб “Різні програми за одним кодом”. Це означає один загальний код для всіх програм на різних платформах.

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

# 2) Аутентифікація та авторизація

Вони в основному використовуються у веб-сервісах SOAP. Загалом, автентифікація означає перевірку чогось, тоді як авторизація означає надання / отримання права на доступ до чогось.

Наприклад - Якщо у мене є сторінка у Facebook, то мене можуть розглядати як автентифікованого користувача Facebook. Якщо ви маєте право переглядати мої фотографії на facebook, ви є авторизованим користувачем.

Поєднуючи ці два, ми можемо сказати, що «Усі автентифіковані користувачі, які мають доступ до ресурсів, відомі як Авторизовані користувачі цих ресурсів».

Те саме відбувається у Веб-службах, тобто ідентифікатор користувача та пароль, які використовуються для генерації маркера, охоплюють частину автентифікації, а цей маркер, який буде використовуватися для надсилання запиту на веб-сервер, охоплює частину авторизації.

# 3) Архітектура, що зв’язана між собою

Веб-сервіси базуються на архітектурі, що зв’язана між собою. Це означає, що інтерфейси Веб-служб за своєю суттю є динамічними (змінюються протягом певного періоду). Але логіка клієнта не обов'язково повинна змінюватися під час взаємодії зі службою.

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

# 4) Артефакт

Це термін, який використовується у Веб-службах для позначення інформації або даних. Це не цілі дані, а частина інформації, яка може включати URL-адресу або URI, контекстний ключ, ключ документа, корисне навантаження або допоміжні зображення.

# 5) Кінцева точка

Це дуже поширений термін, який використовується у кожному запиті веб-служби. Це повна URL-адреса, яка потрапляє в екземпляр веб-служби.

Наприклад - https://www.facebook.com/imsaket -> це повна URL-адреса або кінцева точка, URL-адресою якої є facebook.com, а «imsaket» передається як контекстний ключ для однозначної ідентифікації конкретної адреси.

найкраще безкоштовне програмне забезпечення для ремонту Windows 10 -

# 6) Ідемпотент

Це стосується взаємодії клієнт-сервер, при якій не має значення, скільки разів ви натискаєте на екземпляр служби, і сервер завжди поверне клієнту ту саму відповідь.

# 7) Маршалінг та демаршелінг

Як ми знаємо, інкапсуляція - це принцип OOPS, який визначається як зведення коду та даних в один. Те саме відбувається у веб-сервісах SOAP. Коли ми обертаємо або інкапсулюємо дані в корисне навантаження (XML), щоб сформувати повідомлення SOAP і відправити його на сервер, тоді цей процес інкапсуляції називається маршаллінгом.

Демаршалінг - це лише взаємність Маршаллінгу. Метод декапсуляції або розгортання даних та коду (XML) із повідомлення SOAP називається “Демаршалінг”.

Що таке веб-служба?

Як вже обговорювалося раніше, веб-служби - це послуги, які обслуговуються від одного комп'ютера до іншого через мережу.

Приклад веб-служб: AWS (Amazon Web Services), що дозволяє онлайн-користувачам переглядати ціни на різні товари, що продаються на Amazon.com та Amazon.in

Компоненти веб-служб

Нижче наведено різні компоненти веб-служб.

# 1) МИЛО

Веб-служби використовують Простий протокол доступу до об’єктів (SOAP), який використовує XML як корисне навантаження або тіло запиту. Це державний протокол оскільки не існує незалежного методу для конкретного типу операції.

Всі запити та відповіді передаються одночасно через XML, і ніяких незалежних методів, таких як GET, PUT, POST або DELETE, явно не надано.

# 2) WSDL

Цей запит SOAP використовує Мова опису веб-служб (WSDL) що є дуже корисним компонентом веб-служби.

Це визначає, де фактично знаходиться Веб-служба, а також тип Веб-служби, яку потрібно вибрати для конкретного запиту. Це використовує файл XML, що описує функціональність веб-служби.

# 3) UDDI

Ще одним корисним компонентом є UDDI . Це означає універсальний опис виявлення та інтеграції. Існує постачальник послуг, який надає веб-послугу. Отже, для певного постачальника послуг цей UDDI використовується для опису, виявлення та публікації цих веб-служб.

UDDI відповідає за те, щоб клієнт міг дізнатися (UDDI забезпечує сховище для WSDL), де знаходиться XML-файл WSDL. Ось як визначається та описується веб-служба.

# 4) XML-RPC

Це означає Extensible Markup Language - віддалена процедура. Іншим дуже важливим компонентом веб-служби є XML - RPC, який відповідає за передачу повідомлень між системами. Запити та відповіді мають форму XML і надсилаються / отримуються через HTTP POST.

Найкраща особливість XML-RPC полягає в тому, що клієнтська програма, що знаходиться на іншій платформі, може спілкуватися з іншим сервером. Існує щось під назвою JSON-RPC, що було пояснено у другій частині статті, оскільки воно не є компонентом веб-служби.

Архітектура веб-служби

Архітектуру веб-служби можна зобразити на наступній схемі.

Архітектура веб-служб

Як ми вже знаємо, типова архітектура веб-служб включає три сутності, тобто клієнт, веб-сервер та Інтернет для здійснення операції. Операція - це не що інше, як запит і відповідь в архітектурі клієнт-сервер.

Клієнт, як правило, являє собою набір усіх програм або програмних систем, які вимагають веб-службу, тим самим роблячи її споживачем послуг.

Веб-сервер - це сукупність усіх програм або програмних систем, що надають Веб-послугу. Кожна веб-служба вимагає роботи мережі, і це призводить до третьої сутності, яка називається Інтернет.

Це лише огляд архітектури веб-служби.

Робоча схема веб-служби визначається трьома компонентами, показаними нижче.

  • Запитувач послуг (Знайти ())
  • Постачальник послуг (Publish ())
  • Реєстр послуг або сховище (Bind ())

Це пояснюється (детально на схемі) в архітектурі SOAP-служби.

перемикач голосу, який працює з розбіжностями

Типи веб-служб

Два типи веб-служб докладно описані нижче.

# 1) Сервіс SOAP

Служба SOAP розшифровується як Простий протокол доступу до об’єктів. Служби SOAP - це служби з підтримкою стану, які використовують мову XML для формування конверта. Конверт SOAP можна описати двома порціями, тобто один - a Заголовок і тіло SOAP , інший - протокол використовується для надсилання SOAP-повідомлень.

Цей заголовок SOAP складається з автентифікації та авторизації, що надає доступ. Основне тіло потрапляє до розділу корисного навантаження запиту, який використовує WSDL для опису веб-служби, а протокол - це переважно HTTP (протокол передачі гіпертексту).

Безпека веб-служб

Служби SOAP мають рівень SSL (Secure Socket Layer), який відповідає за уникнення витоку даних під час передачі, і таким чином забезпечує шифрування та дешифрування.

Тим часом сервіси SOAP є більш безпечними, оскільки вони також мають WSS (Web Services Security), що гарантує відсутність розголошення під час зв'язку між службою та додатком.

Як ми всі знаємо, кожна веб-служба (на відміну від веб-API) потребує мережі для здійснення своєї роботи. Таким чином, веб-службам необхідно забезпечити безпеку при підключенні до мережі. Отже, веб-служби мають три важливі сутності, які повинні покривати фактор безпеки під час передачі повідомлень.

  • Аутентифікація та авторизація (Вже пояснено вище).
  • Конфіденційність: Це повністю залежить від SSL, який забезпечує шифрування та дешифрування конверта SOAP.
  • Безпека мережі: Це означає витяг усіх відповідей SOAP та XML - RPC, які ви отримуєте від сервера. Наприклад, Якщо ви берете будь-який інструмент веб-служби, такий як POSTMAN або PARASOFT, ви виявите, що під менеджером заголовків HTTP є можливість встановити значення Content-Type. Значення можна встановити як Application / JSON, щоб воно витягувало всі REST (оскільки служби SOAP не підтримують параметри менеджера заголовків HTTP). Таким чином, ви можете передати тип вмісту: Application / XML у файл корисне навантаження у формі XML. Це також дозволить отримати SOAP та XML-RPC.

Ці три фактори становлять безпеку веб-служб для подолання зовнішніх атак.

Архітектура SOAP-сервісу

Кожна служба SOAP залежить від трьох об'єктів, які в кінцевому підсумку формують архітектуру SOAP-служби.

  • Постачальник послуг: Усі програмні системи або програми, які є частиною або надають веб-послугу.
  • Запитувач послуг: Усі програмні системи або програми, що є частиною запитів веб-служби у постачальника послуг.
  • Реєстр послуг: Реєстр або сховище, де вся інформація про Веб-послугу надається Постачальником послуг. (Вже обговорено в UDDI)

Пояснення

Архітектура послуг SOAP

Ці три сутності взаємодіють між собою для успішного впровадження веб-сервісу. Це робиться у три фази. Перший етап - це Опублікувати () етап, коли Постачальник послуг подає всі деталі про Веб-службу в Реєстр послуг або Сховище.

Другий етап Знайти () де Сервісний запит, головним чином, клієнтська програма знаходить детальну інформацію про веб-службу зі сховища (також має XML-файл WSDL). Остання фаза - Прив'язка () де клієнтська програма або Запитувач послуг синхронізується з Постачальником послуг для остаточного впровадження Веб-служби.

# 2) RESTful сервіс

REST означає 'Представницький державний трансфер', який є Без громадянства Обслуговування.

Він називається Stateless, оскільки веб-сервер не зберігає жодної інформації про сеанс клієнта (тривалість часу до підключення та виконання клієнтської програми), що означає, що кожен тип запиту обробляється та виконується легко за допомогою вбудованих методів REST, таких як GET, POST, CUSTOM (PUT), DELETE, HEAD тощо.

Дійсно, цих методів у SOAP немає.

Метод або Дієслова

Кожен метод у REST має своє значення. Нижче наведено брифінг про кожного з них.

  • ОТРИМАТИ: Цей метод використовується для отримання інформації, яка надсилається на сервер за допомогою будь-якого з методів, таких як PUT або POST. Тут немає органу запиту. Успішне виконання дасть вам 200 об'єктів відповіді.
  • ПОСТ: Цей метод використовується для створення документа або запису за допомогою тіла запиту, вказаної URL-адреси, ключа документа, контекстного ключа тощо. Те саме можна отримати за допомогою методу GET. Успішне виконання дасть вам 201 відповідь.
  • ВСТАНОВИТИ: Це під опцією CUSTOM, яка доступна в POSTMAN або PARASOFT. Цей метод використовується для оновлення будь-якого документа або запису, який уже є. Успішне виконання дасть вам відповідь 201 або 200.
  • ВИДАЛИТИ: Цей метод використовується для видалення будь-якого запису. Успішне виконання дасть вам відповідь 204 (без вмісту).

Примітка: Коди відповідей HTTP залежать від того, як розробники кодують, і ними можна часом маніпулювати. Ми перерахували загальні коди відповідей, які ми отримуємо від кожного типу методу.

Архітектура служби відпочинку

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

Клієнтська програма, яка зазвичай є Споживачем послуг, використовує вбудовані методи REST, URL-адресу або URI, версію HTTP та корисне навантаження (якщо підтримується методом).

Архітектура сервісу REST

МИЛО проти РЕСТ

Хоча ці два типи веб-служб використовуються для здійснення запиту та відповіді, вони абсолютно різні за своїм способом роботи.

Їх відмінності наведено для довідки.

яка операційна система Windows найкраща
  • Конверт SOAP можна використовувати в REST, але не навпаки. Наприклад Токен користувача, створений у SOAP, може бути переданий у запиті REST під менеджером заголовків HTTP -> Авторизація.
  • SOAP, як правило, більш безпечний, ніж REST-послуги, оскільки SOAP-послуги забезпечують WSS, крім SSL. Цей SSL присутній як у SOAP, так і в REST.
  • SOAP повільніший за REST, оскільки обробка запиту займає більше часу в SOAP завдяки формату даних XML. REST використовує JSON, який є дуже легким і таким чином робить його швидшим.
  • SOAP не має жодного вбудованого методу, але REST має GET, PUT, POST тощо.
  • SOAP має статус, тоді як REST - без громадянства.
  • Тіла запитів та відповідей у ​​SOAP підтримують лише формат даних XML. У REST органи запиту та відповіді підтримують багато форматів даних, таких як JSON, XML, звичайний текст тощо.

Висновок

Цей підручник з веб-служб пояснив архітектуру, компоненти та типи веб-служб.

Ми також дізналися про відмінності між SOAP та REST-послугами, а також про інші важливі концепції та термінології, пов’язані з веб-службами.

Ми сподіваємось, що цей посібник допоміг вам зрозуміти веб-служби !!

НАЗАД Підручник | НАСТУПНИЙ підручник

Рекомендована література

^