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.
More globally, consider your client-side application as just a consumer. There may be others, which are on the same level. For instance, you may have a JavaScript application which runs in browsers, an Android and an iOS application to run on mobile devices, and a desktop app for PCs. All those apps should be using the same server side application.
By using REST, you can decouple even more your server side application from its client counterparts (JavaScript one, Android app, desktop app, etc.) The server application becomes what is called a service.
Generate client-side code from server-side code where the business rules are the same. In ASP.NET MVC, this is what happens with field validation. You don't write any JavaScript code for that: you simply add validation attributes to your model, and the framework takes care of generating the corresponding JavaScript for you to have client-side validation which matches exactly the server-side validation.
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.
If JavaScript interaction is removed, either all those forms would be shown permanently, and would clutter the page, or they will still be hidden away, appearing as hypertext links. In this second case, I would have to wait until another page is shown just to get a simple share link, which is not exactly how I imagine spending my time on this site.
Independently of the presence of JavaScript, the web app (REST service; whatever) should only return information intended for the user. This is true for a website with no client-side interactivity, as this is true for an app which heavily relies on AJAX.
because it would be easily hack-able and someone can take benefit of it.
As previously stated, independently on the presence of JavaScript, the web app should always return only information the user is allowed to see.
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.
