Abstract away backend

[jfinkels]

Adds abstraction layer for backend specific code, so that it is easier to add new backends later.

[jfinkels]

Fixes issue #61 and #36.

[schlamar]

As already said in #50, I really would like to see a more general backend so you are not tied up to databases explicitly.

So a stack like this would be great:

Backend  <-- DatabaseBackend <-- SQLAlchemyBackend

There are many use cases, for example a RPC to REST mapper, a backend for an existing application without API or a caching backend between flask and the database (or any other backend).

[schlamar]

I think there are not many changes needed to achieve this generalization.

The most important (but very easy) step is to change the terminology. You should start talking about resources and fields instead of models and columns.

The query interface needs to be changed so it is independent from an SQL style. Maybe splitting it in multiple parts would make sense here.

I am missing an update_from_dict(resource, data) function (or didn't see any equivalent).

[schlamar]

About the query. It would be very easy if you make the query format dependent on the backend. So it could like:

def query(resource, session, query_data):
    ...

Another word for session might be good, too. [backend_]provider or something like that.

[jfinkels]

I'm not totally convinced that it makes sense to turn this project into a generic library that works for all web frameworks/all database backends.

1. If you want such a thing, I think it would be better to, for example, translate https://github.com/toastdriven/django-tastypie into Flask. Which I don't want to do. I'm not saying that it's not a valiant goal (I imagine it would be very useful), it's just something I'm not interested in working on.
2. Writing for all possible database backends and all possible web frameworks, we lose some of the simplicity provided by using a single framework-backend pair. I would like the code for this library to rely, in particular, on the unique style provided by Flask, and the unique style provided by SQLAlchemy. In this way, we can create a compact, single-purpose extension which fits in well with a project using both Flask and Flask-SQLAlchemy.

So although your suggestions are great, I probably won't pursue this line of work. But if you want to make a pull request with the proposed changes, I will of course consider it.

[jfinkels]

I'm closing this as a "wont' fix", because I don't feel it is worth my time to pursue this goal.