There's nothing to "install", you just have to have the four PHP files uploaded in place (the "index.php" is the request handler -- the page URL that your web users will talk to, the "config.php" is your database credentials info, and the two files in the "lib" directory are the classes that do all of the real work). Since you aren't allowed to run a "naked" API (you need to have a working web site on the account), you would need to use a subdirectory of public_html. (You can use as a subdomain or add-on domain to get a more "RESTfully pure" URL if having, say, "/api/" in the URL looks ugly to you.) There are no binaries or anything else special to deal with; it's just some standard PHP files that need to be uploaded.
That leaves you with two problems. The first is that you need both the server and the client to understand and permit both the PUT and DELETE HTTP verbs/methods if you need to update and delete (POST and GET for the create and read part of CRUD can be taken for granted). You have no control over the server if you're not running a VPS (or dedicated/colo machine), so the server may or may not understand PUT and DELETE on any given day, depending on how the admins have felt about it lately. You never have control over the client except on your own machine, so if you're expecting users who may be tightly firewalled (at work or at school), or users with old browsers (and I'm really very sorry if that's the case) you may not have the PUT or DELETE verbs available to you.
The second is something that's entirely under your control, and that's managing user actions. And, really, that's not safe at all. Remember that everything that happens in the database will happen as your database user who has all permissions. User authentication is not a problem; you can use the same authentication/session mechanism you are using for the rest of the site. (You just need to add session_start(), etc., to the API's index.php, and verify that the user is only doing things you want them to do. Yeah, that's kind of hand-wavy, I know, but it's the same sort of thing you'd have to do with an ordinary site.) The real problem is that you don't have access to HTTPS on Free Hosting, so your API and user credentials -- the session id and any other authentication tokens you may be using -- are exposed as plaintext to anyone that might be listening/sniffing. Since the whole point of the API is the next best thing to SQL injection (you can't create or drop tables, but you can delete everything in the table easily enough or upload malicious JSON), you need to be extremely careful about what you allow to happen before you create an ArrestMySQL object and really grok the fact that a malicious user or third party has all of the power that you don't deliberately take away from them. (Blacklisting actions is a fool's game. Forbid everything you don't whitelist.)
So you have three tasks ahead of you if you want to use this. The first is to move the config.php to somewhere outside of your public_html and modify the include path. That way if the server ever serves PHP directly instead of processing it, you don't have your database, user and password showing up in anybody's browser. That's pretty standard.
The second is to modify the index.php substantially to add all of the authentication and authorization/verification you need to limit user activity and make the API as safe as it can be over HTTP. And do keep it mind that "as safe as it can be over HTTP" isn't all that safe.
The third, not mentioned at all so far, is to modify lib/db.php. It uses the mysql_xxx PHP functions, which have been deprecated in the current version of PHP. You can pretty much drop in the mysqli_xxx equivalents without too much work, and it would be a relative snap to use prepared statements. Because it's going to take some development and testing of index.php on a local machine to make this thing safe enough to use anyway, the extra few minutes it takes to update the mysql_xxx stuff to methods/functions that won't throw errors or warnings (and that won't simply go away in a few months or years) isn't going to be much of a burden.
