This section briefly describes the options available in spring-test for Spring MVC applications.

  • Servlet API Mocks: Mock implementations of Servlet API contracts for unit testing controllers, filters, and other web components.

  • TestContext Framework: Support for loading Spring configuration in JUnit and TestNG tests, including efficient caching of loaded configuration in test methods and support for loading WebApplicationContext with MockServletContext.

  • Spring MVC Test: A framework, also known as MockMvc, designed for testing annotated controllers via DispatcherServlet (i.e. annotation-aware), bundled with the Spring MVC framework, but without HTTP server.

  • Client-side REST: spring-test provides a MockRestServiceServer that can be used as a mock server to test client-side code that internally uses RestTemplate .

  • WebTestClient: Built for testing WebFlux applications, but can also be used for end-to-end integration testing on any server over an HTTP connection. It is a non-blocking, reactive client that is well suited for testing in asynchronous and streaming scenarios.

WebSocket protocol

This portion of the reference documentation covers support for the servlet stack, WebSocket messaging including raw WebSocket interactions, WebSocket emulation via SockJS, and publish-subscribe messaging via STOMP as a subprotocol on top of WebSocket.

Java university

Introduction to the WebSocket protocol

The WebSocket protocol, RFC 6455, provides a standardized way to establish a full-duplex two-way communication channel between a client and server over one TCP connection. This is a different TCP protocol than HTTP, but is designed to run on top of HTTP, uses ports 80 and 443, and allows you to reuse existing firewall rules.

WebSocket communication begins with an HTTP request that uses the Upgrade HTTP header to upgrade, or in this case, migrate to the WebSocket protocol. The following example shows this interaction:

GET /spring-websocket-portfolio/portfolio HTTP/1.1
Host: localhost:8080
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: Uc9l9TMkWGbHFD2qnFHltg==
Sec-WebSocket-Protocol: v10.stomp, v11.stomp
Sec-WebSocket-Version: 13
Origin: http://localhost:8080
  1. Header Upgrade.
  2. Using the Upgrade connection.

Instead of the normal 200 status code, the WebSocket-enabled server issues a message similar to the following:

HTTP/1.1 101 Switching Protocols 
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: 1qVdfYHU9hPOl4JYYNXF623Gzn0=
Sec-WebSocket-Protocol: v10.stomp
  1. Protocol switch

After a successful handshake, the TCP socket underlying the HTTP update request remains open so that the client and server can continue to send and receive messages.

A complete introduction to the WebSocket protocol is beyond the scope of this document. See "RFC 6455", the chapter on WebSockets in HTML5, or any of the many descriptions and tutorials on the Internet.

Note that if the WebSocket server is running behind a web server (such as nginx), it will likely need to be configured to pass WebSocket update requests to the server. Likewise, if your application is running in a cloud environment, check your cloud provider's instructions regarding WebSocket support.

HTTP vs WebSocket

Even though the WebSocket protocol is designed to be HTTP-compatible and originate from an HTTP request, it is important to understand that the two protocols entail completely different architectures and application programming models.

In HTTP and REST, an application is modeled as a set of URLs. To interact with the application, clients access these URLs in a request-response style. Servers route requests to the appropriate handler based on the URL, method, and HTTP headers.

In contrast, WebSockets typically use only one URL for the initial connection. Subsequently, all application messages are transmitted over the same TCP connection. This points to a completely different asynchronous, event-driven messaging architecture.

WebSocket is also a low-level transport protocol that, unlike HTTP, does not impose any semantics on message content. This means that there is no way to route or process the message until the semantics of the message are agreed upon between the client and server.

Clients and servers on a WebSocket can negotiate the use of a higher-level messaging protocol (such as STOMP) by using the Sec-WebSocket-Protocol header in the HTTP handshake request. In the absence of this, they need to come up with their own agreements.

When should you use WebSockets?

WebSockets protocol can make a web page dynamic and interactive. However, in many cases, a combination of Ajax and an HTTP stream or long-form polling can be a simple and effective solution.

For example, news, mail and social feeds should be updated dynamically, but it is quite acceptable to do this every few minutes. On the other hand, collaboration apps, games, and financial apps need to run in real time more often.

The delay itself is not a decisive factor. If the volume of messages is relatively small (for example, when monitoring network failures), streaming or polling over the HTTP protocol can be an effective solution. It is the combination of low latency, high frequency and high volume that is the best argument in favor of using WebSocket.

Remember also that on the Internet, restrictive proxies that are beyond your control may prevent WebSocket communications, either because they are not configured to send the Upgrade header or because they close long-lived connections , which appear to be inactive. This means that using WebSocket for internal applications within a firewall is a simpler solution than for public applications.