We moved our native mobile apps from a direct connection to our PostgreSQL servers to use a RESTful API built in Rails. While not a desktop app nor Omnis, I think it’s a valuable comparison. Some pros:
- Flakey connections are much easier to handle since there is no persistent TCP connection to maintain.
- We adhere to the JSON API spec which prescribes some powerful features like field sets and included data. This allows the client to tune and express “queries” without needing extra backend development.
- We can deploy fixes and enhancements on the backed without requiring an app update.
- If done properly, versioning provides and incredible amount of flexibility and agility to support multiple clients simultaneously and decouple backend development from your apps.
- Using authentication tokens is great for security. Set them to auto-expire and you’ve got a much less vulnerable system than a persistent database user with predefined rights.
- It’s slower. Even with caching, which adds extra work and complexity, you’re still bouncing through extra layers to serialize data to JSON and back again. There’s also extra overhead to hold the results in both a JSON format and native objects during deserialization.
- App developers’ work can be blocked waiting for the backend developers to add new functionality.
- We’ve pushed code to our backend for years with stored procedures, views, and custom types. (PostgreSQL is awesome!) One of the selling points of a RESTful server is to migrate your business logic out of your app and into the middle tier. For us, this is moot and sometimes results in duplicated work where certain endpoints or actions just expose a stored procedure.
- To build on the previous point, you have to re-imagine your data into endpoints and handle complex operations in a single POST or PUT. For work that involves touching many tables, like posting accounting entries, this is no small feat.
That last point is a big one. Our mobile apps provides very lightweight data entry features–they’re mostly for consuming information and making small updates. With a RESTful app there are no transactions, so each action needs to survive atomically, or we have to build a single endpoint that updates multiple tables all at once. This can present not only unique design challenges, but even require an altered user experience to allow for all your data collection up front that drives to a single POST. We have an Ember app that uses the same API to make more involved changes in the data, and it absolutely works, but the app is built so that each step collects the data for the final action, and the blasts it to the API in one POST. Your desktop app might need some work to move to that model.
Are we thinking about using REST against an API to access data from our Omnis apps? Yes, and we already do this a tiny bit for our account discovery service. I can see a RESTful approach working well in some cases, but a direct connection excelling in others.