The old API Pattern was designed in the 70's for centralized architectures and binds it's communication logic to it's business logic so that I/O cannot be shared with other services in an architecture without duplication. We will show a new API Pattern that fixes this issues by abstraction the communication layer away from business logic thus enabling sharing of I/O, better scale, less code, and faster processing as well as many other things.

1. RestFest 2017
orubel@gmail.comOwen Rubel
The New API Pattern

2. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
First Lets Understand The Difference Between
Centralized and Distributed Architectures…
Understanding The API Pattern

3. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
Centralized vs Distributed Architecture
Centralized Architecture (Unshared I/O)
Distributed Architecture (Shared I/O)
microservices
monolith application
monolith application
proxy MQapp
server
Client Client
ClientClient
(CORS,security) (caching,security)

4. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
• How many developers still use a centralized architecture vs a
distributed architecture in their development?
Centralized vs Distributed Architecture

5. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
• How many developers still use a centralized architecture vs a
distributed architecture in their development?
• How many developers used a centralized architecture for their
development 5 years ago? 10 years ago?
Centralized vs Distributed Architecture

6. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
• How many developers still use a centralized architecture vs a
distributed architecture in their development?
• How many developers used a centralized architecture for their
development 5 years ago? 10 years ago?
• Over the last 20+ years, there has been a trend toward distributed
architectures due to separation of services/concerns, micro
services, and Aspect Oriented Programming
Centralized vs Distributed Architecture

7. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
“ An API is Standardized Input/Output (I/O) to/from
a Separation of Concern (usually being Business
Logic).”
In Short :
What Is An API? (1 OF 2)

8. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
What Is An API? (2 OF 2)
owenr@uw.edu

9. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
“ 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
What Is Separation of Concern? (1 of 2)

10. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
What Is Separation of Concern? (2 of 2)
Bound Secondary
Concern
(Communication
Logic)
Primary
Concern
(Business Logic)

11. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
API Pattern in Distributed Architecture

12. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
API Pattern in Distributed Architecture
Bound I/O Data
and/or Functionality
DUPLICATED I/O Data DUPLICATED I/O Data

13. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
API Pattern in Distributed Architecture
Cross Cutting Concern

14. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
“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 where 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
What is a Cross Cutting Concern?

15. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
• 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 of a Cross Cutting Concern

16. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
This is The API Patterns Brick Wall
Brick Wall

17. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
• API’s were created in 70’s to standardize information
exchanged between services
• 70’s api pattern was designed for centralized
architecture; distributed architectures didn't exist.
• Web API’s were based on 70’s api pattern; Roy Fielding
based his work on this pre-existing pattern.
• Web API’s were integrated into MVC frameworks and
tools; it is now used everywhere.
• JAX-RS and other tools were based on old patterns as
they bind to business logic
Why Did This Happen? (1 of 2)

18. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
• Distributed Architectures are a New Pattern. Old principles
and patterns are often not re-examined unless an issue is
discovered. In the case of API’s, they are a tried and true
pattern and still work locally… but not ‘distributed’
• People ASSUMED the resource was the endpoint; The
controller hands the resource OFF to the communication layer.
The communication layer hands off I/O to other services in a
distributed architecture. Hence, the communication layer is the
endpoint.
Why Did This Happen? (2 of 2)

19. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
So How Do We Fix?
Title Text

20. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
Old API Pattern in MVC
redirect/response

21. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
New API Pattern in MVC

22. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
New API Pattern In Distributed Architecture

23. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
This allows:
• Central Piece of architecture (where REQUEST AND RESPONSE
are handled) to be ‘Single Version of Truth’ (SOV) called ‘IO State’
• All services to sync data from SOV
• Failure of SOV DOES NOT affect synchronization of data
• Reload state on the fly at SOV and update ALL subscribed services
Shared IO State

24. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
So What Is IO State?

25. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
What is IO State?
• Caches Communications Data
• Synchronizes Architectural Props (distribute rules of communication)
• Handles API Authorizations (access for communication)
• Api Docs Definitions (how to communicate)
I/O State is data directly related to a request/response, normally
separated from functionality. Handles all data associated with
communication and communication access

26. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
What Does IO State Contain
•all the data contained in annotations act as rules associated with the
URI endpoint (not URL or the FQDN)
•by containing all those rules in one file and caching that data, we can
share it with the other architectural components (and abstract data from
functionality)
•this enables us to change it on the fly and reload without having to
restart any services allowing subscribed services to get changes
pushed to them through web hooks

27. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
I/O State : Communications Properties
Shared I/O State is ‘IO State’ data unbound from
functionality so that it can be shared across architectural
components. This is the approach used by distributed
architectures.
Bound I/O State is ‘I/O State’ data bound to functionality
which cannot be shared or synchronized with additional
architectural components creating an ‘architectural cross
cutting concern’. This is commonly found in centralized
architectures.

28. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
Shared I/O State
• DOESN’T bind to the application
• DOESN’T bind to functionality
• DOESN’T bind to a resource

29. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
What Does It Look Like?
Title Text
https://gist.github.com/orubel/7c4d0290c7b8896667a3

30. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
• Api Blueprint, Swagger, RAML
• not role based
• confuses I/O state with content/resource
• based on annotations and thus not sharable in distributed architecture
• duplicitous; lack of separation

31. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
• 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) )
What Does It Improve?

32. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
Code Reduction (1 of 2)
Controller : Mixed Concerns (Duplication)
@Secured(['ROLE_ADMIN', ‘ROLE_USER'])
@RequestMapping(value="/create", method=RequestMethod.POST)
@ResponseBody
public ModelAndView createAddress(){
List authorities = springSecurityService.getPrincipal().getAuthorities()
User user
if(authorities.contains(‘ROLE_ADMIN’)){
if(params.id){
user = User.get(params.id.toLong())
}else{
render(status:HttpServletResponse.SC_BAD_REQUEST)
}
}else if(authorities.contains(‘ROLE_USER’)){
user = User.get(principal.id)
}
Address address = new Address(params)
…
address.user = user
…

33. Title Text
RestFest 2017
orubel@gmail.comOwen Rubel
Code Reduction (2 of 2)
Controller : Single Concern
public ModelAndView createAddress(){
User user= (params.id)?User.get(params.id.toLong()): User.get(principal.id)
Address address = new Address(params)
address.user = user
…
}

34. RestFest 2017
orubel@gmail.comOwen Rubel
Questions?
(please contact for business opportunities or hiring)
Just Open Sourced At RestFest
• https://github.com/orubel/beapi_backend