REST срещу WebSockets

1. Общ преглед

В този урок ще разгледаме основите на комуникацията клиент-сървър и ще проучим това чрез две популярни опции, налични днес. Ще видим как WebSocket, който е нов участник, се сравнява с по-популярния избор на RESTful HTTP.

2. Основи на мрежовата комуникация

Преди да се задълбочим в детайлите на различните опции и техните достойнства и недостатъци, нека бързо освежим пейзажа на мрежовата комуникация. Това ще помогне да се поставят нещата в перспектива и да се разбере по-добре.

Мрежовите комуникации могат да бъдат най-добре разбрани от гледна точка на модела за взаимосвързаност на отворените системи (OSI).

Моделът OSI разделя комуникационната система на седем слоя на абстракция:

В горната част на този модел е слоят Application, който представлява интерес за нас в този урок. Ще обсъдим обаче някои аспекти в четирите слоя, докато сравняваме WebSocket и RESTful HTTP.

Приложният слой е най-близо до крайния потребител и е отговорен за взаимодействието с приложенията, участващи в комуникацията. Има няколко популярни протокола, които се използват в този слой като FTP, SMTP, SNMP, HTTP и WebSocket.

3. Описване на WebSocket и RESTful HTTP

Въпреки че комуникацията може да се случи между произволен брой системи, ние сме особено заинтересовани от комуникацията клиент-сървър. По-конкретно, ще се съсредоточим върху комуникацията между уеб браузър и уеб сървър. Това е рамката, която ще използваме, за да сравним WebSocket с RESTful HTTP.

Но преди да продължим по-нататък, защо да не разберем бързо какви са те!

3.1. WebSockets

Както гласи официалната дефиниция, WebSocket е комуникационен протокол, който предлага двупосочна, пълна дуплекс комуникация през постоянна TCP връзка. Сега ще разберем всяка част от това изявление в детайли, докато продължаваме.

WebSocket беше стандартизиран като комуникационен протокол от IETF като RFC 6455 през 2011 г. Повечето съвременни уеб браузъри днес поддържат протокола WebSocket.

3.2. Отпочиващ HTTP

Въпреки че всички сме наясно с HTTP поради повсеместното му присъствие в интернет, той също е протокол за комуникация на приложен слой. HTTP е протокол , базиран на заявка-отговор , отново ще разберем това по-късно в урока.

REST (Reprezentative State Transfer) е архитектурен стил, който поставя набор от ограничения върху HTTP за създаване на уеб услуги.

4. WebSocket Subprotocol

Докато WebSocket дефинира протокол за двупосочна комуникация между клиент и сървър, той не поставя никакво условие върху съобщението, което ще се обменя . Това остава отворено за страните в съобщението да се споразумеят като част от преговори за подпротокол.

Не е удобно да се разработи подпротокол за нетривиални приложения. За щастие има много популярни подпротоколи като STOMP, достъпни за използване . STOMP е съкращение от Simple Text Oriented Messaging Protocol и работи през WebSocket. Spring Boot има първокласна поддръжка за STOMP, която ще използваме в нашия урок.

5. Бърза настройка в Spring Boot

Няма нищо по-хубаво от това да видите работещ пример. Така че, ние ще изградим прости случаи на употреба както в WebSocket, така и в RESTful HTTP, за да ги изследваме допълнително и след това да ги сравним. Нека създадем прост сървър и клиентски компонент и за двете.

Ще създадем прост клиент с помощта на JavaScript, който ще изпрати име. И ние ще създадем сървър, използващ Java, който ще отговори с поздрав.

5.1. WebSocket

За да използваме WebSocket в Spring Boot, ще ни трябва подходящ стартер:

 org.springframework.boot spring-boot-starter-websocket 

Сега ще конфигурираме крайните точки на STOMP:

@Configuration @EnableWebSocketMessageBroker public class WebSocketMessageBrokerConfig implements WebSocketMessageBrokerConfigurer { @Override public void registerStompEndpoints(StompEndpointRegistry registry) { registry.addEndpoint("/ws"); } @Override public void configureMessageBroker(MessageBrokerRegistry config) { config.setApplicationDestinationPrefixes("/app"); config.enableSimpleBroker("/topic"); } }

Нека бързо дефинираме прост сървър WebSocket, който приема име и отговаря с поздрав:

@Controller public class WebSocketController { @MessageMapping("/hello") @SendTo("/topic/greetings") public Greeting greeting(Message message) throws Exception { return new Greeting("Hello, " + HtmlUtils.htmlEscape(message.getName()) + "!"); } }

И накрая, нека изградим клиента за комуникация с този WebSocket сървър. Тъй като наблягаме на комуникацията между браузър и сървър, нека създадем клиент в JavaScript:

var stompClient = null; function connect() { stompClient = Stomp.client('ws://localhost:8080/ws'); stompClient.connect({}, function (frame) { stompClient.subscribe('/topic/greetings', function (response) { showGreeting(JSON.parse(response.body).content); }); }); } function sendName() { stompClient.send("/app/hello", {}, JSON.stringify({'name': $("#name").val()})); } function showGreeting(message) { $("#greetings").append("" + message + ""); }

Това завършва нашия работен пример за WebSocket сървър и клиент. В хранилището на кода има HTML страница, която осигурява прост потребителски интерфейс за взаимодействие.

Въпреки че това просто надрасква повърхността, WebSocket с Spring може да се използва за изграждане на сложни клиенти за чат и други.

5.2. Отпочиващ HTTP

Ще преминем през подобна настройка за услугата RESTful сега. Нашата проста уеб услуга ще приеме GET заявка с име и ще отговори с поздрав.

Нека вместо този път използваме уеб стартера на Spring Boot:

 org.springframework.boot spring-boot-starter-web 

Сега ще определим REST крайна точка, използвайки мощна поддръжка за анотиране, налична през пролетта:

@RestController @RequestMapping(path = "/rest") public class RestAPIController { @GetMapping(path="/{name}", produces = "application/json") public String getGreeting(@PathVariable("name") String name) { return "{\"greeting\" : \"Hello, " + name + "!\"}"; } }

И накрая, нека създадем клиент в JavaScript:

var request = new XMLHttpRequest() function sendName() { request.open('GET', '//localhost:8080/rest/'+$("#name").val(), true) request.onload = function () { var data = JSON.parse(this.response) showGreeting(data.greeting) } request.send() } function showGreeting(message) { $("#greetings").append("" + message + ""); }

Това е почти всичко! Отново има HTML страница в хранилището на кода, която да работи с потребителски интерфейс.

Although profound in its simplicity, defining production grade REST API can be much more extensive task!

6. Comparison of WebSocket and RESTful HTTP

Having created minimal, but working, examples of WebSocket and RESTful HTTP, we're now ready to understand how do they fare against each other. We'll examine this against several criteria in the next sub-sections.

It is important to note that while we can directly compare HTTP and WebSocket as they are both application layer protocols, it's not natural to compare REST against WebSocket. As we saw earlier REST is an architectural style which leverages HTTP for communication.

Hence our comparison to WebSocket will mostly be regarding the capabilities, or lack thereof, in HTTP.

6.1. URL Scheme

A URL defines the unique location of a web resource and mechanism to retrieve it. In a client-server communication, more often than not we're looking to get static or dynamic resources through their associated URL.

We're all familiar with the HTTP URL scheme:

//localhost:8080/rest

WebSocket URL scheme is not much different either:

ws://localhost:8080/ws

At the outset, the only difference seems to be the characters before the colon, but it abstracts a lot which happens under the hood. Let's explore further.

6.2. Handshake

Handshakerefers to the automatic way of negotiating communication protocol between communicating parties. HTTP is a stateless protocol and works in a request-response mechanism. On every HTTP request, a TCP connection is established with the server over the socket.

The client then waits until the server responds with the resource or an error. The next request from the client repeats everything as if the previous request never happened:

WebSocket works very differently compared to HTTP and starts with a handshake before actual communication.

Let's see what comprise a WebSocket handshake:

In case of WebSocket, the client initiates a Protocol Handshake request in HTTP and then waits until the server responds accepting an upgrade to WebSocket from HTTP.

Of course, since Protocol Handshake happens over HTTP, it follows the sequence from the previous diagram. But once the connection is established, from there on client and server switches over to WebSocket for further communication.

6.3. Connection

As we saw in the previous subsection, one stark difference between WebSocket and HTTP is that WebSocket works on a persistent TCP connection while HTTP creates a new TCP connection for every request.

Now obviously creating new TCP connection for every request is not very performant and HTTP has not been unaware of this. In fact, as part of HTTP/1.1, persistent connections were introduced to alleviate this shortcoming of HTTP.

Nevertheless, WebSocket has been designed from the ground up to work with persistent TCP connections.

6.4. Communication

The benefit of WebSocket over HTTP is a specific scenario that arises from the fact that the client can server can communicate in ways which were not possible with good old HTTP.

For instance, in HTTP, usually the client sends that request, and then the server responds with requested data. There is no generic way for the server to communicate with the client on its own. Of course, patterns and solutions have been devised to circumvent this like Server-Sent Events (SSE), but these were not completely natural.

With WebSocket, working over persistent TCP communication, it's possible for server and client both to send data independent of each other, and in fact, to many communicating parties! This is referred to as bi-directional communication.

Another interesting feature of WebSocket communication is that it's full-duplex. Now while this term may sound esoteric; it simply means that both server and client can send data simultaneously. Compare this with what happens in HTTP where the server has to wait until it receives the request in full before it can respond with data.

While the benefit of bi-directional and full-duplex communication may not be apparent immediately. we'll see some of the use-cases where they unlock some real power.

6.5. Security

Last but not least, both HTTP and WebSocket leverage the benefits of TLS for security. While HTTP offers https as part of their URL scheme to use this, WebSocket has wss as part of their URL scheme for the same effect.

So the secured version of URLs from the previous subsection should look like:

//localhost:443/rest wss://localhost:443/ws

Securing either a RESTful service or a WebSocket communication is a subject of much depth and can not be covered here. For now, let's just say that both are adequately supported in this regard.

6.6. Performance

We must understand that WebSocket is a stateful protocol where communication happens over a dedicated TCP connection. On the other hand, HTTP is inherently a stateless protocol. This has an impact on how these will perform with the load but that really depends on the use case.

Since communication over WebSocket happens over a reusable TCP connection, the overhead per message is lower compared to HTTP. Hence it can reach higher throughput per server. But there is a limit to which a single server can scale and that is where WebSocket has issues. It's not easy to horizontally scale applications with WebSockets.

This is where HTTP shines. With HTTP each new request can potentially land on any server. This implies that to increase overall throughput we can easily add more servers. This should potentially have no impact on the application running with HTTP.

Obviously an application may itself need state and session stickiness which can make it easier said than done.

7. Where Should We Use Them?

Now, we have seen enough of RESTful service over HTTP and simple communication over WebSocket to form our opinion around them. But where should we use what?

It's important to remember that while WebSocket has emerged out of shortcomings in HTTP, it's not, in fact, a replacement of HTTP. So they both have their place and their uses. Let's quickly understand how can we make a decision.

For the bulk of the scenario where occasional communication is required with the server like getting the record of an employee, it's still sensible to use REST service over HTTP/S. But for newer client-side applications like a stock-price application which requires real-time updates from the server, it's much convenient to leverage WebSocket.

Generalizing, WebSocket is more suitable for cases where a push-based and real-time communication defines the requirement more appropriately. Additionally, WebSocket works well for scenarios where a message needs to be pushed to multiple clients simultaneously. These are the cases where client and server communication over RESTful services will find it difficult if not prohibitive.

Независимо от това, използването на WebSocket и RESTful услуги през HTTP трябва да се извлече от изискванията. Тъй като няма сребърни куршуми, не можем просто да очакваме да изберем един, който да реши всеки проблем. Следователно трябва да използваме нашата мъдрост, съчетана със знания, при проектирането на ефективен модел на комуникация.

8. Заключение

В този урок разгледахме основите на мрежовата комуникация с акцент върху протоколите на приложния слой HTTP и WebSocket. Видяхме няколко бързи демонстрации на WebSocket и RESTful API през HTTP в Spring Boot.

И накрая, сравнихме характеристиките на протоколите HTTP и WebSocket и накратко обсъдихме кога да използваме всеки от тях.

Както винаги, кодът за примерите е достъпен в GitHub.