While there are many schools of thought on this, and certainly no one way can be called "the right way" universally, while all others are "the wrong way" universally, there are a number of reasons to isolate business logic on the server side, and access those objects and services through a RESTful service.
The short answer is that it's mostly about risk management, and performance monitoring and improvement.
The number 3 reason is performance. Business logic can potentially be demanding of server and database resources. By keeping that logic isolated from your UI elements, you can then scale out just that portion of your application, making it that much easier to address bottlenecks. Additionally, it's much easier to isolate which business process is loading your system or database backends if the business processes are executed on the server.
A corollary here is that often several business processes will use the same data, and so you can implement caching on the server side to reduce overall system load that might not be possible/secure to give clients side code access to.
Finally, I would propose that in order to maintain ACID standards, Business Logic really does need to be on the server. I remember maintaining a billing product that ran in the web browser, with only a database connection to the server. If the daily billing (which could take an hour or more on a good day!) were interrupted, say, by the browser being closed or crashing, it could take several hours to sort out the mess it made of the database, which was left in an inconsistent state. Remember, this also involved credit cards, so the billing records had to be checked against the processor too!
Server side business logic is mostly trivial to ensure ACID updates, as there any frameworks for any language to maintain transactions, either at an application or database level. If you're doing this via multiple updates from a web client... you're going to get inconsistent state at some point, and it's likely going to affect your application.
While it can be tempting to think of RESTful services as simply a way to access the database, you shouldn't fall into this trap, as it's a good recipe for disaster. The object model you expose via a RESTful service can be related to your database, but should really encapsulate your business logic instead of just using it as a CRUD engine.