RESTLink

RESTLink on github.

RESTLink is my own attempt at what seems to be a common problem - exposing common backend resources (like a database table) to the internet via a REST API. Solutions to this problem litter the flask ecosystem. However, many of them are abandoned and the only ones that still thrive are somewhat limited in scope.

This sort of problem probably doesn't have a general solution. The complexity possible in connecting an accessor API to a database is immense. For example, what if an SQL view is to be exposed? What if database session is handled in an unusual (or even just different) way? I find it telling that the seeming current 'winner' in the space (connexion) is not a classical extension to Flask and requires one to instantiate connexion's version of the Flask app.

So with RESTLink I seek to solve a problem that's broad in context but narrow in scope. Time and time again, I simply need to open a simple table up to a REST API. Oh, permissions might be more or less complicated and foreign keys might create a complex series of tabular relations, but the need is always the same.

Nine times out of ten I simply want to automate the exposure of a table to a REST API on the internet. And RESTLink can construct that toolchain almost completely automatically, as long as the project that uses it adheres to some (admittedly very specific) conditions.

RESTLink does the following entirely automatically:

• Generate and expose REST HTTP routes for a backend resource.
• Link those routes to data access methods for the resource.
• The programmer should not have to write dedicated get(), put(), etc. methods unless they are unusual.
• Generate and expose API documentation on the basis of its configuration.
• Tentative | Testing of access to defined resources.

And in order to do this, the programmer shall only have to:

• Define and configure Schema's.
• Define an authentication method.
• Define backend resource general access methods.
  • For example, automatic access to a database will require a properly configured SQLAlchemy Session instance.

Status Quo

I am not the first and surely not the last to attempt to solve this problem. Below I've summarized some of existing solutions to this problem and why they aren't quite what I need.

• Flask-RESTPlus - Older version of Flask-RESTX. Seemingly abandoned by creator.
• Flask-RESTX - Elegant solution, but only covers the step from defining Resources (e.g. Schema's). Tied exclusively into Flask and has no provisions for automating the database step. Stops at allowing the programmer to define custom get/update/etc. method.
• Connexion - One of the better attempts at this out there. The programmer writes the documentation and everything just works. However, this level of power comes with a pretty high cost - the central application instance must be an instantiation of connexion's own application class.

Future Plans and Ideas

Memcaching could be pretty easily integrated as a configurable option. It would take the load off the database (presuming a good method of expiring cache could be found). Configuration options could include a max amount of memory for use. The underlying algorithm could keep rolling averages of request metrics in memcache as well in order to choose what to keep in cache. If the only methods allowed for modifying the resource are the actual REST methods (GET/POST/PUT/ETC), then there does not need to be a cache-expiry method. PUT would update or expire cache, etc.