The API pattern was created in the 1970's when 'distributed architectures' didn't even exist and was established mainly for 'centralized architectures' as it bound the communication data/logic to the business logic. In a modern world, we have moved to distributed architectures where we now have to share the I/O... but that communication logic still remains bound in the application due to an old API pattern. This makes it so that the IO data and functionality related to a request/response cannot be shared with our edge services without duplication/entanglement. This in turn means the data/functionality in our services then cannot be synchronized. This leads to dropped threads, poor security, bad data, bad user experience, broken application, etc. This can ALL be fixed and improved and even lead to better speed, scalability and automation through a new API Pattern.

1. The New API Pattern
Owen Rubel

2. What is an API?
“ An API is Standardized Input/Output (I/O) to and from a Separation of Concern
(usually being Business Logic).”
In Short :

3. What is Separation Of Concern?
“ In computer science, separation of concerns (SoC) is a design principle for
separating a computer program into distinct sections, such that each section
addresses a separate concern. A concern is a set of information that affects the
code of a computer program” (ex HTML, CSS, JS)
- Source : Separation Of Concern, Wikipedia

4. About The OLD API Pattern
• API’s were created in 70’s to standardize information exchanged between
services
• 70’s pattern was designed for centralized architecture; distributed architectures
didn't exist.
• Web API’s were based on 70’s pattern; Roy Fielding based his dissertation on
this pre-existing pattern.
• Web API’s were integrated into MVC frameworks and tools; it is now used
everywhere.

5. What Is The OLD API Pattern? (1 of 4)

6. What Is The OLD API Pattern? (2 of 4)
!!!WARNING!!! CROSS CUTTING CONCERN
!!!WARNING!!! CROSS CUTTING CONCERN
Primary
Concern
(Business Logic)
Secondary
Concern
(Communication Logic)

7. What Is The OLD API Pattern? (3 of 4)
• annotations
• restful controllers
Bindings done through:
Biz Logic &
Bound I/O Logic/Data

8. What Is The OLD API Pattern? (4 of 4)
Bound I/O Data
and/or Functionality
Duplicated I/O Data
and/or Functionality
Duplicated I/O Data
and/or Functionality
!!!WARNING!!! CROSS CUTTING CONCERN
!!!WARNING!!! CROSS CUTTING CONCERN

9. What Is A Cross Cutting Concern
“Cross-cutting concerns can be directly responsible for tangling, or system inter-
dependencies, within a program. Because procedural and functional language
constructs consist entirely of procedure calling, there is no semantic through
which two goals (the capability to be implemented and the related cross-cutting
concern) can be addressed simultaneously.[3] As a result, the code
addressing the cross-cutting concern must be scattered, or duplicated,
across the various related locations, resulting in a loss of modularity.[2]”
- Source : Cross Cutting Concern, Wikipedia

10. Cross Cutting Concern Examples
• Synchronization (*)
• Real-time constraints
• Error detection and correction
• Product features
• Memory management
• Data validation (*)
• Persistence (*)
• Transaction processing
• Internationalization and localization which includes Language localisation
• Information security
• Caching (*)
• Logging (*)
• Monitoring
• Business rules (*)
• Code mobility
• Domain-specific optimizations (*)
* issues specifically affecting old API pattern
when applied to distributed architecture

11. Issues of Architectural Cross Cutting Concern With IO
This causes:
• Dropped Threads
• Duplicitous code/data
• Higher I/O overhead
• Lack of synchronization of duplicitous code/data
• Polluted Business Rules
• Polluted Security Rules
• Polluted Domain Rules
• Polluted Endpoint Logic
• Polluted Logging
• and more

12. Why Did This Happen?
• Distributed Architectures are a New Pattern and people did not examine
old patterns that share I/O before applying them. They also did not
question people who applied old patterns to new ones.
• People ASSUMED the resource was the endpoint; since it is I/O that is
shared, communication is the endpoint. It is communication that would route
back to itself during an automated batch job… not the controller. The
controller hands the resource OFF to the communication layer

13. So How Do We Fix?

14. The NEW API Pattern: Abstracting API Layer

15. The NEW API Pattern: Synchronize IO State

16. Solution
This allows:
• Central Piece of architecture (where REQUEST AND RESPONSE are
handled) to be ‘Single Version of Truth’ (SOV)
• All services to sync data from SOV
• Failure of SOV to not affect synchronization of data
• Reload on the fly to occur through SOV and update ALL subscribed services

17. Additional Improvements of New Pattern
• Dramatic Code reduction By Reducing Duplication
• Automation of nearly all aspects of API
• Nearly 0% downtime for changes to endpoint data and rules
• New API Patterns (ie API Chaining (tm) )

18. Questions?