On Apr 19, 2012, at 9:54 AM, Nate Angell wrote:

> Perhaps there are ways to ensure both a current API and enact your
> thinking to improve performance/stability/consistency.

Good notes Nate.  I come at this from a somewhat different perspective, and 
advocate an approach that may or not work in the context of OAE. All of this 
may be impossible in the current architecture, so take it with a grain of salt. 

I assume the existence of an *automatically generated* back-end API, which 
makes all data in the system (and all combinations of queries / joins / writes 
/ deletes / updates etc.) available from anywhere in our internal codebase, 
plus a separate public API that exposes a limited subset of that as JSON for 
external services to consume or write to. 

In other words, our own code could do something like this:

dead_instructors = Instructor.objects.filter(profile__user__active=false)
dead_instructors.delete()

(and that would automatically do a cascade delete, removing all data objects 
that are dependent on the deleted instructors = no "dark matter").

That API would exist automatically because the system would have internal 
awareness of all data models. We would never have to worry about keeping the 
internal API up to date - it would take care of itself. Likewise, I imagine a 
system where the biz logic does a query for a view like:

course = get_object_or_404(Course,id=1234)

and sends that course object directly to the template system, without having to 
first serialize the output to JSON, spew it across http to a back-end consumer, 
only to be  immediately digested and then have more code generate a DOM from 
that. 

In  other words, the difference is this:

OAE:
query --> JSON over http --> template system --> html over http

Other frameworks:
query --> template system --> html over http

In the second scenario, we skip  an http cycle and maybe a 
serialize/deserialize step. And we vastly simplify development. All made 
possible by having an automatically maintained internal API.

As for the public API, I'm not convinced there's a need to have it mirror 
*everything*. Public restful APIs only need to expose a limited subset of data 
and operations, and with far less expressive power than the back-end API. I 
honestly don't see the big win in having the the two APIs be one and the same. 

My .02,
Scot


__________________________
Scot Hacker
Senior Software Developer @ CalCentral
Educational Technology Services, UC Berkeley

[email protected]
(510) 292-5586
__________________________







_______________________________________________
oae-dev mailing list
[email protected]
http://collab.sakaiproject.org/mailman/listinfo/oae-dev

Reply via email to