User:Orubel/API Abstraction
 | This is not a Wikipedia article: It is an individual user's work-in-progress page, and may be incomplete and/or unreliable. For guidance on developing this draft, see Wikipedia:So you made a userspace draft. Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
API Abstraction is the separation of cross cutting concerns related to the API within an architecture to better enable externalization to architectural concerns. In API functionality, all API's are an implementation of two sets of functions: I/O and resource gathering. Within an architecture where the I/O is shared, the API I/O also becomes a shared concern and needs to be a separated from resource creation so that architectural tooling can better make use of the communication layer. This separation of the communication concern from the api is what is known as 'api abstraction'. Not only does this enable easier externalization, synchronization and sharing of the environment with external architecture but this also enables API developers to reload the api configuration on the fly, have DRY'r code, easier batching, api chaining, reduced code, synchronized configuration/security, reduced throughput and more.
History
[edit]Created in the fall of 2013 as part of the Grails API Toolkit by Owen Rubel, it was released in February 2014 and documented in May of the same year. It was later presented that same year at APIDays Berlin and SpringOne 2GX. Early adoption has initially been slow but there has been great interest in the methodology for the architectural problems it solves. Interest from companies like Mashery, Apple, Paypal has already brought significant notice to the methodologies.
Currently, this functionality is being added extended to Node.js and spring-boot with other frameworks and toolkits in the works.
APIObject
[edit]API Abstraction is handled through the declaration of a common object called an 'apiObject' which is declared externally and loaded into a common storage system (ie MongoDb, MySQL, etc). Upon start, each tool can read and cache the objects as they wish and then use them with each request without having to make further calls. Should the apiObject need to be reloaded, a webhook can push the update to all systems subscribe to the loading daemon process.
API Chaining
[edit]One of the biggest benefits of API Abstraction is the functionality known as API Chaining. As a result of separating the communication concern from the api, we can create an I/O monad within the application allowing API calls to call one another but stay within the confines of the original request. This allows us to apply all api checks and security checks with each call as we loop through each call.
Though this is often confused with method chaining, this is quite different in the fact that the client sets state and declares the API's to be called for each part of the chain as well as their corresponding method. In method chaining, no state is set and only the first method is declared; all chaining is done on the backend on the server. But in API Chaining, the client declares the REST method for each api in the chain and declares all parts of the chain to be called.
Furthermore, API Chaining is done through an I/O monad making use of a prehandler and posthandler so the initial request is never left; all secondary requests are chained off the initial request and happen internally without having to do a forward outside of the application/architecture. Method chaining uses forward which LEAVE the original request and often exit the server and come back in via a secondary request with each call.
See also
[edit]