If the server only serves entities and values (so doesn't serve DOM parts), and doesn't build html, encoding values creates encoding issues because the part which integrates these values into the DOM is already supposed not to trust its inputs, which results in double encoding problems.
I think the role of such a server (which doesn't build DOM but only stores and serve data) is not to sanitize inputs. However, it can still validate inputs early and return a 400 Bad Request if an attack pattern is detected. This way, the server contributes to protection against XSS without all problems of data modification due to sanitizing.
I think sanitizing server-side must be reserved to the servers which build DOM server-side: which serve HTML pages or HTML page parts.
But if DOM is modified client-side, the JS code must not trust its input and prevent from XSS injections.
Problem is: in Java, OWASP security libraries offer APIs to sanitize HTML but not to only valisate it. To do so, I've found the hibernate annotation @SafeHtml which uses JSoup and can be used easily on DTO fields with @Valid annotation to enable validation on a class/method/parameter.