Not all RESTful APIs will fit into a framework like this, and the choice of RethinkDB limits its applicability to a narrower community, but I intend on supporting other document-based DBs in the future. I really like RethinkDB's API and ReQL in particular, and it seems like a solid foundation to build something a little out of the ordinary on.
What makes it different from other ORMs? It's a rethinking of ORM mechanics for a "document-based" backend system.
* It tries to make the exposure of non-CRUD operations relate as a method to a logical server-side object and have a consistent endpoint syntax. It also uses Python function annotations to generate request and response schemas for methods.
All API endpoints exist within a four-tiered path hierarchy of
* Suite - base level, serves as a collection of applications and repo for basic shared schemas
* Application - a bundle of collections representing a logical set of functionality, methods that bind at this level act like "library functions"
* Collection - a collection of documents sharing a common schema. Methods that bind at this level act like "class methods"
* Document - a single instance of a document schema, representing concrete data. Methods that bind at this level act like "instance methods" in traditional OO programming.
What helper features does it have?
* Reusable apps / collections.
* JWT based sample authentication app, auth.
* Automatically generated help from schema descriptions and python docstrings
* Self-describing schema endpoints for suites, applications, collections, documents, and their methods.
This is pre-release stuff, to be sure. I'm using it on personal projects, but it needs:
* More tests
* More docs for the Python side of things (I'm working on this first)
Not all RESTful APIs will fit into a framework like this, and the choice of RethinkDB limits its applicability to a narrower community, but I intend on supporting other document-based DBs in the future. I really like RethinkDB's API and ReQL in particular, and it seems like a solid foundation to build something a little out of the ordinary on.
What makes it different from other ORMs? It's a rethinking of ORM mechanics for a "document-based" backend system.
* JSON documents are validated using JSON-Schema (http://json-schema.org).
* It tries to make the exposure of non-CRUD operations relate as a method to a logical server-side object and have a consistent endpoint syntax. It also uses Python function annotations to generate request and response schemas for methods.
All API endpoints exist within a four-tiered path hierarchy of
* Suite - base level, serves as a collection of applications and repo for basic shared schemas
* Application - a bundle of collections representing a logical set of functionality, methods that bind at this level act like "library functions"
* Collection - a collection of documents sharing a common schema. Methods that bind at this level act like "class methods"
* Document - a single instance of a document schema, representing concrete data. Methods that bind at this level act like "instance methods" in traditional OO programming.
What helper features does it have?
* Reusable apps / collections.
* JWT based sample authentication app, auth.
* Automatically generated help from schema descriptions and python docstrings
* Self-describing schema endpoints for suites, applications, collections, documents, and their methods.
This is pre-release stuff, to be sure. I'm using it on personal projects, but it needs:
* More tests
* More docs for the Python side of things (I'm working on this first)
* A solid example application
* Automatic generation of JS API connectors