REST vs WebSockets

1. Ikhtisar

Dalam tutorial ini, kita akan membahas dasar-dasar komunikasi klien-server dan menjelajahi ini melalui dua opsi populer yang tersedia saat ini. Kita akan melihat bagaimana WebSocket, yang merupakan peserta baru, bersaing dengan pilihan HTTP RESTful yang lebih populer.

2. Dasar-dasar Komunikasi Jaringan

Sebelum kita mendalami detail berbagai opsi dan kelebihan serta kekurangannya, mari kita segarkan lanskap komunikasi jaringan dengan cepat. Ini akan membantu untuk menempatkan segala sesuatunya dalam perspektif dan memahami ini dengan lebih baik.

Komunikasi jaringan dapat dipahami dengan baik dalam kerangka model Open System Interconnection (OSI).

Model OSI membagi sistem komunikasi menjadi tujuh lapisan abstraksi:

Di bagian atas model ini adalah lapisan Aplikasi yang menjadi minat kami dalam tutorial ini. Namun, kami akan membahas beberapa aspek dalam empat lapisan teratas saat kami membandingkan WebSocket dan RESTful HTTP.

Lapisan aplikasi paling dekat dengan pengguna akhir dan bertanggung jawab untuk berinteraksi dengan aplikasi yang berpartisipasi dalam komunikasi. Ada beberapa protokol populer yang digunakan di lapisan ini seperti FTP, SMTP, SNMP, HTTP, dan WebSocket.

3. Mendeskripsikan WebSocket dan RESTful HTTP

Meskipun komunikasi dapat terjadi antara sejumlah sistem, kami sangat tertarik pada komunikasi klien-server. Lebih khusus lagi, kami akan fokus pada komunikasi antara browser web dan server web. Ini adalah bingkai yang akan kita gunakan untuk membandingkan WebSocket dengan RESTful HTTP.

Tetapi sebelum kita melangkah lebih jauh, mengapa tidak segera memahami apa itu!

3.1. WebSockets

Seperti definisi formal, WebSocket adalah protokol komunikasi yang menampilkan komunikasi dua arah, full-duplex melalui koneksi TCP persisten. Sekarang, kita akan memahami setiap bagian dari pernyataan ini secara mendetail saat kita melanjutkan.

WebSocket distandarisasi sebagai protokol komunikasi oleh IETF sebagai RFC 6455 pada tahun 2011. Sebagian besar browser web modern saat ini mendukung protokol WebSocket.

3.2. HTTP tenang

Meskipun kita semua tahu tentang HTTP karena keberadaannya di mana-mana di internet, ini juga merupakan protokol komunikasi lapisan aplikasi. HTTP adalah protokol berbasis permintaan-respons , sekali lagi kita akan memahami ini lebih baik nanti di tutorial.

REST (Representational State Transfer) adalah gaya arsitektur yang menempatkan sekumpulan batasan pada HTTP untuk membuat layanan web.

4. Subprotokol WebSocket

Sementara WebSocket mendefinisikan protokol untuk komunikasi dua arah antara klien dan server, itu tidak menempatkan kondisi apa pun pada pesan yang akan dipertukarkan . Ini dibiarkan terbuka bagi pihak-pihak dalam komunikasi untuk menyetujui sebagai bagian dari negosiasi subprotokol.

Tidaklah mudah mengembangkan subprotokol untuk aplikasi non-sepele. Untungnya, ada banyak subprotocol populer seperti STOMP yang tersedia untuk digunakan . STOMP adalah singkatan dari Simple Text Oriented Messaging Protocol dan bekerja melalui WebSocket. Spring Boot memiliki dukungan kelas satu untuk STOMP, yang akan kami gunakan dalam tutorial kami.

5. Pengaturan Cepat di Spring Boot

Tidak ada yang lebih baik daripada melihat contoh yang berfungsi. Jadi, kita akan membuat kasus penggunaan sederhana di WebSocket dan RESTful HTTP untuk menjelajahinya lebih jauh dan kemudian membandingkannya. Mari buat server sederhana dan komponen klien untuk keduanya.

Kami akan membuat klien sederhana menggunakan JavaScript yang akan mengirimkan nama. Dan, kami akan membuat server menggunakan Java yang akan merespons dengan salam.

5.1. WebSocket

Untuk menggunakan WebSocket di Spring Boot, kami memerlukan starter yang sesuai:

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

Kami sekarang akan mengonfigurasi titik akhir 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"); } }

Mari kita dengan cepat menentukan server WebSocket sederhana yang menerima nama dan merespons dengan salam:

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

Terakhir, mari buat klien untuk berkomunikasi dengan server WebSocket ini. Saat kami menekankan komunikasi browser-ke-server, mari buat klien dalam 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 + ""); }

Ini melengkapi contoh kerja server dan klien WebSocket kami. Ada halaman HTML di repositori kode yang menyediakan antarmuka pengguna sederhana untuk berinteraksi.

Meskipun ini baru menyentuh permukaan, WebSocket dengan Spring dapat digunakan untuk membangun klien obrolan yang kompleks dan banyak lagi.

5.2. HTTP tenang

Kami akan melalui pengaturan serupa untuk layanan RESTful sekarang. Layanan web sederhana kami akan menerima permintaan GET dengan nama dan menanggapi dengan salam.

Mari kita gunakan web starter Spring Boot sebagai gantinya kali ini:

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

Sekarang, kami akan menentukan titik akhir REST yang memanfaatkan dukungan anotasi canggih yang tersedia di Spring:

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

Terakhir, mari buat klien di 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 + ""); }

Cukup banyak itu! Sekali lagi, ada halaman HTML di repositori kode untuk bekerja dengan antarmuka pengguna.

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.

Namun demikian, penggunaan WebSocket dan layanan RESTful melalui HTTP perlu diambil dari persyaratannya. Seperti tidak ada peluru perak, kita tidak bisa hanya berharap untuk memilih satu untuk menyelesaikan setiap masalah. Karenanya, kita harus menggunakan kearifan kita ditambah dengan pengetahuan dalam merancang model komunikasi yang efisien.

8. Kesimpulan

Dalam tutorial ini, kami meninjau dasar-dasar komunikasi jaringan dengan penekanan pada protokol lapisan aplikasi HTTP dan WebSocket. Kami melihat beberapa demonstrasi cepat WebSocket dan RESTful API melalui HTTP di Spring Boot.

Dan terakhir, kami membandingkan fitur protokol HTTP dan WebSocket dan membahas secara singkat kapan harus menggunakannya.

Seperti biasa, kode untuk contoh tersedia di GitHub.