API Chaining and API Abstraction

[Owen Rubel]

So am bringing this conversation over from Twitter. Imposible to describe API abstraction in the application (not the architecture) with the use of API objects on Twitter. I always use API chaining as a demo of capabilities for reduced calls, throughput, increased security, automation, etc.

Basically API's have always followed the traditional thought pattern of URL -> DATA because of the way the web was built but because we have to tie alot of functionlity into the API (security, rules, data checking etc), while making this be client definable and accesable, and backwards compatible, we need to separate the api layer within the application from the other functional components to allow for simpler access from the frontend.

So I proposed the api be treated like what it is... a comm layer and be tied more directly to the request/response rather than to the data which is what is sent and returned; the api actually is a set of rules for handling what is sent and returned and has little to do with the actual functionality. In reality, it acts as the 'doorman' for the data coming in and going out.

To this extent, I associated the REST model with an object (even extending it beyond REST for testing purposes), and assigned privs for the I/O data so checks could be done at the request and the response based on the cached object.

This cached object also can be used to relate to the other objects as well by assigned keys/indexes so that rather than having relations, we have actual objects being related based on their relation to each other similar to ORM. In this sense, you could give a user privilege to the data but NOT to the ID and only allow access through a chain.