One example is a shipping cost calculator for OpenCart.
OpenCart out of the box doesn’t manage inventory distributed across multiple warehouses and other requirements that we have.
I looked into creating a plug in for OpenCart, but I quickly decided that all the PHP I wanted to write was limited to calling a few Anvil endpoints. The Anvil endpoint receives the content of the cart and the shipping address, finds the closest facility, tries different packaging configurations and shipping methods, and returns a list with the shipping methods that make sense. The requests to Google maps for the distances, UPS and FedEx for 3-4 different shipping methods, the calculation of other options takes a few sections and I’m ok with that. Other APIs take care of checking the availability in inventory and allocating the cart items first temporarily, then permanently. An uplink script that runs nightly uploads to an Anvil table about 1000 items from our local inventory (still based on the decrepit Lotus Notes, soon to be replaced by a few Anvil apps).
I decided to use Anvil because Python is easier than PHP, because I didn’t need to mess with the existing database or to setup a new one, because the uplink makes it easy to synchronize our local database with the table on the cloud.
Another example of rest server is an app that stores parameters shared by internal tools, VBA Excel macros, CAD plugins, etc.
The admin interface is an Excel file with thousands of parameters with a button that uploads them to an Anvil table. All the other Excel macros use two endpoints to get the parameters whenever they need them.
I used Anvil because I went from nothing to a working rest server in 15 minutes. Then I spent a few more hours because I added some bells and whistles like authentication, usage statistics, etc.