"Client" and "server" are overloaded words with multiple meanings. Let's break this down a little. The important distinction is between "a machine that runs co

"Client" and "server" are overloaded words with multiple meanings. Let's break this down a little. The important distinction is between "a machine that runs code you control" and "a machine that runs code controlled by someone else". In general, if the code is running on someone else's computer, you don't control it. This is very true for browser Javascript, which visitors can alter at will, but even signed iOS applications are vulnerable to determined attackers. In practice, 99.9% of users won't do this. Especially if the only thing at stake is your dissertation. But in many cases the 0.1% would be enough to potentially bankrupt you. That simple "RESTful API" can be used to delete your database, or (far worse, in many cases) insert fraudulent data… unless the database is protected by authorization logic that you control. (Authorization logic is no laughing matter. It's generally application-specific. Is it okay for an arbitrary user to add 1 to this database column? Depends on whether the column represents "number of visits per day" or "number of dogecoin paid out per second". Repeat this design exercise for every possible permutation of every transaction. Then watch what happens when you accidentally let user X publish unsanitized text to a column which will eventually be printed verbatim on HTML page Y containing script Z...) To control a piece of code, you have to run it on a machine that is physically secure, and that nobody but you ever touches. If it is networked, the machine must sit at a documented, permanent location on that network (i.e. "have an SSL certificate vouching for its IP address"), and be behind a network firewall to keep the attack surface down. At which point, no matter what it looks like or what ports it listens on, this machine is going to be called "a server". And once you've accepted a server into your system you may as well take advantage of it: You can use programming languages besides Javascript, runtimes other than a browser, APIs that browsers don't have, hardware that browsers can't access, and much richer interfaces to your data than REST. It is also true that the boxes we call "servers" are designed to run 24/7, have more durable and redundant network connectivity, have redundant power, have fast pipes connecting them to other servers, and be rented by the hour for a few cents. But, compared to the issues of ownership and control, these are implementation details.