You're considering your application as an architect. For a software architect, it would indeed make much more sense to put all business logic on server side. For a developer, it would be great as well: there are a lot of difficulties developers have to overcome when having part of the logic on server side, part of the logic on client side, and part of the logic on both sides at the same time.
Instead, you may consider your application from the perspective of a user. For a user, SoC doesn't mean anything. SOLID principles? Layers? Don't care. What the user cares about is performance and user experience. Imagine a registration form. The user has to enter a user name and type twice a password. One application would run AJAX queries to check if the user name is already in use, or do a match between two password fields to inform the user in real time that the values don't match. Another application would wait until the user submits the form to inform him that something went wrong. Which one is faster and more comfortable to use?
As a software architect, when you have to write a web application which has logic on server side and on client side, you may:
Consider that you have two applications. The client-side one simply interacts with the server-side one. This would ensure that the design principles are limited to one application considered in isolation.
Make it explicit which business rules belong to client side, and which ones should remain on the server. The goal, here, is to avoid for your team to search for the rule in the wrong place, or, worse, reinvent the wheel by rewriting the rule which was already implemented on the other side.
Following the comments about security aspects:
I don't want to expose data layer or service layer on client side.
That's good, because you shouldn't.
Exposing a data layer is practically like giving your SQL credentials to the users and letting them access and manage the data.
This is why, in my answer, I was saying that you should consider that you have two applications: client-side app and server-side app. You don't expose your data layer to the Internet; what you expose is the interface of the server-side application which was specifically designed to be accessed through the Internet.
For an example, I don;t want whole JSON to be returned on HTML page and on HTML page I should be writing a logic to display/hide/calculate something.
If a given client is not expected to see the specific information, the information should not be included in the JSON response. For instance, there is no way for me to get your YouTube watch history through Google's API. I know the endpoint which returns the watch history, and I may even ask you to give me your account identifier to be passed to the API. But unless you explicitly authorized me to read your history, I will never be able to see it, no matter how hard I try.
The purpose of the display/hide logic which runs on client side is to enhance the user experience by showing only what is relevant to the user at a given moment.
For instance, on the page you're looking on right now, there is a question, and there is an answer; there is no dialog which allows me to share your question or my answer, and there is no window which allows me to cast a close vote or to flag your question. There is no form to add a comment either. All those missing parts are hidden behind small “share,” “edit,” “close,” “flag” and “add a comment” pieces of text which, in turn, populate the corresponding windows. This behavior is very convenient: when I read a question, I don't necessarily want to close it, nor do I immediately want to share it. Occasionally, I want to do so, in which case a simple click shows me the relevant controls.
because it would be easily hack-able and someone can take benefit of it.
A REST service is by no means easier to hack than an app which returns HTML, because there is nothing special about REST. In both cases, the server processes a request and returns some text in response. The fact that the text looks like JSON and not HTML has no effect on the security.
Source code that sits on the client-side is easily readable and capable of being reverse-engineered if it has been obfuscated.
In terms of security, this is irrelevant: if you rely on security through obscurity, you're pretty much screwed anyway.