З RESTful HTTP у вас є система запитів / відповідей без стану, де клієнт надсилає запит, а сервер повертає відповідь.
З webSockets у вас є система передачі повідомлень із станом (або, можливо, зі статусом), де повідомлення можна надсилати в будь-який спосіб, і надсилання повідомлення має нижчі накладні витрати, ніж при запиті / відповіді RESTful HTTP.
Це досить різні конструкції з різною міцністю.
Основними перевагами підключеного webSocket є:
Двостороння комунікація. Отже, сервер може повідомити клієнта про що завгодно в будь-який час. Отже, замість опитування сервера через певний проміжок часу, щоб побачити, чи є щось нове, клієнт може встановити webSocket і просто прослуховувати будь-які повідомлення, що надходять з сервера. З точки зору сервера, коли відбувається подія, що цікавить клієнта, сервер просто надсилає повідомлення клієнту. Сервер не може зробити це за допомогою простого HTTP.
Зменшення накладних витрат на повідомлення. Якщо ви передбачаєте велику кількість трафіку, що протікає між клієнтом і сервером, тоді на повідомлення з веб-сокетом є менші накладні витрати. Це пов’язано з тим, що TCP-з’єднання вже встановлено, і вам просто потрібно надіслати повідомлення у вже відкритому сокеті. За запитом HTTP REST вам слід спочатку встановити TCP-з'єднання, яке складається з декількох пунктів між клієнтом та сервером. Потім ви надсилаєте запит HTTP, отримуєте відповідь і замикаєте TCP-з'єднання. Запит HTTP обов'язково включатиме деякі накладні витрати, такі як усі файли cookie, які вирівняні з цим сервером, навіть якщо вони не стосуються конкретного запиту. HTTP / 2 (найновіша специфікація HTTP) забезпечує певну додаткову ефективність у цьому відношенні, якщо він використовується як клієнтом, так і сервером, оскільки одне TCP-з'єднання може використовуватися не лише для одного запиту / відповіді.
Вища шкала за деяких обставин. З меншими накладними витратами на повідомлення та відсутністю опитування клієнта, щоб з’ясувати, чи є щось нове, це може призвести до додаткової масштабованості (більша кількість клієнтів, які може обслуговувати даний сервер). Є і мінуси масштабованості webSocket (див. Нижче).
Державні зв’язки. Не вдаючись до файлів cookie та ідентифікаторів сеансів, ви можете безпосередньо зберігати стан у своїй програмі для певного з'єднання. Незважаючи на те, що для розв’язання більшості проблем було зроблено багато розробок зв’язку без громадянства, іноді з підключеннями з підтримкою стану це просто.
Основними перевагами RESTful HTTP-запиту / відповіді є:
Універсальна підтримка. Важко отримати більш універсальну підтримку, ніж HTTP. Хоча зараз WebSockets користуються відносно хорошою підтримкою, все ще існують деякі обставини, коли підтримка WebSocket регулярно недоступна.
Сумісний з більшою кількістю серверних середовищ. Існують серверні середовища, які не дозволяють тривалих серверних процесів (деякі ситуації спільного хостингу). Ці середовища можуть підтримувати HTTP-запит, але не можуть підтримувати тривале з'єднання WebSocket.
Вища шкала за деяких обставин. Вимога webSocket для постійно підключеного сокета TCP додає деякі нові вимоги до масштабу до інфраструктури сервера, яких запити HTTP не вимагають. Отже, це закінчується компромісним простором. Якщо переваги webSockets насправді не потрібні або використовуються значним чином, то запити HTTP насправді можуть масштабуватися краще. Це точно залежить від конкретного профілю використання.
Для одноразового запиту / відповіді один HTTP-запит є більш ефективним, ніж встановлення webSocket, використання його та закриття. Це пов’язано з тим, що відкриття webSocket починається із запиту / відповіді HTTP, а після того, як обидві сторони домовились про оновлення до з’єднання webSocket, фактичне повідомлення webSocket може бути надіслане.
Без громадянства. Якщо ваша робота не ускладнюється наявністю інфрастуктури без громадянства, тоді світ без громадянства може значно спростити масштабування або відмову (просто додайте або видаліть серверні процеси за балансиром навантаження).
Автоматичне кешування. За допомогою правильних налаштувань сервера відповіді http можуть бути кешовані браузером або проксі-серверами. Немає такого вбудованого механізму для запитів, надісланих через webSockets.
Отже, щоб звернутися до того, як ви задали питання:
Які підводні камені використання веб-сокетів замість RESTful HTTP?
У великих масштабах (сотні тисяч клієнтів), можливо, вам доведеться виконати деякі спеціальні роботи на сервері, щоб підтримувати велику кількість одночасно підключених веб-сокетів.
Усі можливі клієнти або набори інструментів не підтримують webSockets або запити, зроблені через них, до того самого рівня, який вони підтримують HTTP-запити.
Деякі з менш дорогих серверних середовищ не підтримують тривалі серверні процеси, необхідні для підтримки webSockets.
Якщо для вашої програми важливо повернути клієнтові сповіщення про хід, ви можете або використати тривале HTTP-з'єднання, яке продовжує відправляти прогрес, або ви можете використовувати webSocket. WebSocket, швидше за все, простіше. Якщо WebSocket вам дійсно потрібен лише на відносно короткій тривалості цієї конкретної діяльності, тоді ви можете виявити, що найкращий загальний набір компромісів виходить за допомогою webSocket лише на той час, коли вам потрібна можливість надсилання даних клієнту та потім використання http-запитів для звичайних дій із запитами / відповідями.