The model you suggest sounds awesome!...without evaluating what it would take to get there ;)
I'm not so much advocating for an API that mirrors everything, but an API that is always current, rather than an afterthought. I would like OAE to continue to stand out as a platform that offers unprecedented API access and currency. = nate On Thu, Apr 19, 2012 at 5:53 PM, Scot Hacker <[email protected]> wrote: > 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 _______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
