SlideShare a Scribd company logo
1 of 20
There
is
a
better
way
octo.com
API
Architecture
stra+egy
Quick Reference Card
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

API Levels.
TheAPI level you are targeting can be reflected by the type of consumers you are addressing.
The main difference lies in the way you need to “industrialize” the enrolment process and the
quality required for your API.

At Level 1, if an application developer faces an issue, he can directly meet the guys from the API team
You should target Open API from the beginning (even if you are targeting Level 1 or 2 in the
short term):

So that you can fully industrialize the way developers consume your “services” on your developer portal:
https://developers.fakecompany.com/

This is the only way to offer good enrolment, TTFAC*  support in a digital way
Level 1 « Internal API»
API used by the company
Level 2 « Partner API »
API used by internal developers
 partner developers
Level 3 « Open API »
API used by internal developers, partner
developers  external developers
As soon as we start working on an API, architecture issues arise. Many mistaken common
beliefs turn out to be fiction in this area. A poorly designed API architecture will lead to misuse
or – even worse – not be used at all by its intended clients: application developers.
To facilitate and accelerate design and development of your APIs, we share our vision and beliefs with you in
this Reference Card. They come from our direct experience on API projects.
API Architecture
Strategy.
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

Integrating your legacy SOA
implementations into your API Strategy…
could end up with an URBANIZATION
Strategy
Monitoring, Accounting.
Which API Strategy?
Focusing on the REST approach inspired
by Web Giants… may end up building a
state of the Art API
RESTful, Developer portal, TTFAC*  DX**,
X-device / X-channel.
* “Time To First API Call” is the time a developer needs to consume the API in production after reading the documentation on the developer portal!
We target 5 minutes.
** “Developer experience”. APIs are used by humans. We target a massive adoption, so we should craft them with love.
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

Why an API
strategy ?
“Anytime,Anywhere,Any device” are the key problems of
digitalisation. API is the answer to “Business Agility” as it
allows to build rapidly new GUI for upcoming devices.
An API layer enables

Cross device

Cross channel

360° customer view
Open API allows

To outsource innovation

To create new business
models
Embrace WOA
“Web Oriented Architecture”
Build a fast, scalable  secured
REST API

Based on: REST, HATEOAS,
Stateless decoupled µ-services,
Asynchronous patterns, OAuth2
and OpenID Connect protocols
Leverage the power of your
existing web infrastructure
DISCLAMER
This Reference Card does not claim to be 100% accurate. The design
concepts shown here are a result of our previous work in the REST area.
Please check out our blog http://blog.octo.com, and feel free to comment
or challenge this API cookbook. We’re really looking forward to talking
with you.
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

API Big picture
Architecture:
From SOA to WOA.
SOA (Service Oriented Architecture) fulfilled the promise of breaking down the
monoliths but its implementation came with many pitfalls.
WOA(WebOrientedArchitecture)isasubsetofSOAbasedonRESTfulmicroservices
and tends to correct mistakes from past implementations.
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

SOA* *SOAshouldn’t be confused with its past implementations. From 2000, the
implementation is WS-*/SOAP at 99.%
ARCHITECTURE Service oriented by design:

multiple services can be provided,

results in a huge number of services with slight variations depending on
consumer needs.
RPC approach: abstract of the distributed nature of the WWW network.
MAJOR
IMPLEMENTATIONS 
PROTOCOLS
Heavyweight specific protocols (WS*).
Use custom applicative protocols on top of HTTP and SOAP, that developers
have to learn before calling any service.
Security is based on a VPN or/and complex WS standard designed for server to
server exchanges.
INTEGRATION
PATTERNS
Often implemented through a façade pattern which consists of a monolithic bloc.
Often concentrates complexity in the hands of a centralized ESB tool/team
which has no ownership of business referentials.
Often thinking by vendor  tools first: ESB, BPM, BAM...
CONSUMERS Clients are mostly servers.
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

WOA
ARCHITECTURE Resource-orientedbydesign:ensuresauniquerepresentationofeachresource,
regardless of the number of consumers.
Explicitly assumes the nature of the WWW network: strengths and weaknesses.
MAJOR
IMPLEMENTATIONS 
PROTOCOLS
Simple and based on common Web standards (HTTP, URI, DNS…) used since
the 90s.
Use HTTP as the “universal” applicative protocol. No need to reinvent the wheel
so that developers can quickly use APIs, which offer good affordance.
Security is based on simple Web protocols, device-agnostic by design: OAuth2
and OpenID Connect.
INTEGRATION
PATTERNS
Suits both a façade pattern and a microservices pattern (the last one being the
true distributed nature of the Web).
In a microservices implementation, each API team is fully responsible for their
product:eachteamisresponsibleforthequality(SLA)oftheirresourcesinstead
of putting it into an ESB.
Think API First.
CONSUMERS X-devices: clients are servers, native mobile apps, browsers…
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

SOA SERVICE ORIENTED ARCHITECTURE
SOAP
Service A
HTTP
request
HTML
CSS
JS
Images
APP.
SERVER
MVC
Business Delegate
APP. SERVER
SOA Business Layer
DATA
Database
FAKECOMPANY
Centralized Business
Logic accessible over
the network
- Often implemented
with SOAP
- Potentially can end up
with a huge number of
services with slight
variations depending
on consumer needs.
getProductsA()
getProductsA’()
addProductToCart(1)
updateStock()
validCustomerPayment()
completeOrder()
...
App #1 App
#2
Partner
A
SOAP
Service A’
HTTP
request
Json over
HTTP
APP.
SERVER
REST proxy
SOAP
Services
SOAP
Services
Multiple servers
(one for each
application)
Partner
A’
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

WOA WEB ORIENTED ARCHITECTURE
HTTP
request
HTTP status
(+JSON
+HATEOAS)
APP. SERVER
FAKECOMPANY
µ SERVICES
Independent resources
Agnostic of consumers
Potentially provided by
different teams and
technologies
- GET /products
- PATCH /carts/{product:1}
- PATCH /stocks
- POST /payments
- PATCH /orders
- ...
(REST API based  � services based)
API Gateway
https://api.fakecompany.com/v1/{resouces}
DATA
Database
REST API
/customers
/prospects
APP. SERVER
DATA
Database
REST API
/products
/carts
APP. SERVER
DATA
Database
REST API
/stocks
APP. SERVER
DATA
Database
REST API
/payments
RESTAPI
- Centralized Business Logic
accessible over the network
- HTTP as the universal
applicative protocol
API Gateway
- One single API entry-point
- Monitoring, Throtting
- 360° Customer View
Partner App
#3
REST REST REST REST
App #1 App #2
ATAWAD
- Web single PageApplications
- Native Applications
- ...
Offer a consistent customer
journey
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

SOAP vs REST.
Nick Gall
Portfolio Design Lead at IBM / VP Gartner at Group
“WS-* style Web Services are «Web» in name only… The W3C should
extricate itself from further direct work on SOAP, WDSL, or any other
WS-* specifications”
2007 - https://www.w3.org/2007/01/wos-papers/gall
David Orchard
Principal Engineer at @WalmartLabs / WS standards at BEA
“Given the complexity of just SOAP and WSDL, how many developers
will really be able to move to the full stack?... The promise of WSDL 2.0
has not materialized and is unlikely to do so”
2007 - https://www.w3.org/2007/01/wos-papers/bea
Steve Loughran
Apache Axis committer
“The only place SOAP survives is in the enterprise because if you can
control both ends of the conversation, you can use the same toolkit and
eliminate interop”
2007 - http://www.1060.org/blogxter/
Antoine Chantalou
Head of WOA API at OCTO Technology
“By choosing REST and Web Oriented Architecture, you’re putting all
the chances on your side to succeed in your API strategy… SOAP is an
amazing example of how businesses can embrace complex architectures
and solutions”
2015 - APIdays conference in Paris
INTERVIEW
SOAP
SOAP VS REST:
IT’S ABOUT
ARCHITECTURE
RPC  SOAP

Are operation/service oriented

Tend to unify local and remote computation

Are contract  server oriented
REST

Is resource oriented

Explicitly uses WEB distributed architecture

Is developer oriented
Simplicity wins again
2006 58%
29%
13%
2016
10%
6%
84%
•REST
•SOAP
•Other
Distribution of API
protocols and styles,
based on directory
of APIs listed at
ProgrammableWeb,
May 2016.
SOAP is Not Dead -
It’s a Zombie in the Enterprise.
Your API should be REST based
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

API architecture
stakes.
You should build stateless resource providers. A stateless API provider is easier to
distribute, scale and cache.
Stateless doesn’t mean that there is no state. There are actually two kinds of state:

Clienthandlesapplication/sessionstate:whereyou are in the interaction, navigation,
session.

Server handles only resource state and no session. Each request is self-contained.
STATELESS
A request should always offer low latency. An acceptable response time could be
200ms.
1. On a functional level:
You should switch to an asynchronous flow if response times exceed the limit you
consider acceptable. This limit could be 1s. Technically, the resource provider queues
the request and sends 202 response to the client.
PATCH /orders/007 -d ‘{“status”=“complete”}’
 202 Accepted
When the request is processed, the user is informed by another channel: HTTP2 server
push, websocket, email, sms, or polling.
Asynchronous processing may have heavy impacts on business workflows.
2. On a technical level:
Requests sent by the client should always be asynchronous (XHR for browser’s app).
The resource provider may be asynchronous (see non-blocking/reactive
architectures). You will get a system that is concurrent by design.
Microservices is a key feature of Web OrientedArchitectures.At some point, you may
consider splitting your CORE IT systems into decoupled medium-grained microser-
vices.

Medium grained microservices would be: each resource provider is responsible for
a set of resources that are functionally related

Fine grained microservices would be: each resource provider is responsible for one
resource
Business  technological stakes are:

Short TTM  adaptability
Keep complexity under control
• Small and manageable resource providers
• Limited component lifecycle synchronization

Technology leveraging
• Scalability  performance
• Appropriate technology for the right usage
Note: if you decide to implement microservices, then this requires a compatible orga-
nization and culture (small short-cycle teams and Devops).
ASYNCHRONOUS
MICROSERVICES
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

With REST, you’ll have to drop transactions (from a client point of view). HTTP is not
transactional.
You may manage transactions with one the following solutions:
NON-
TRANSACTIONAL
You may consider Cloud hosting over OnPremise hosting, as API should be as close as
possible to users’ devices to provide an optimum response time:

The “OAuth2 dance” to authenticate and authorize users involves several HTTP calls.

Safe method calls should be cached with standard Web tools.
A WAF RP should not be used. The following issues should be addressed by your API
platform:

DOS/DDOS protection is generally offered by cloud IaaS, PaaS platforms.

Authentication, Authorization, Accounting is provided by OAuth2/OIDC.

Confidentiality, Integrity is provided by TLS.

An RP that forbids any HTTP methods (PUT, PATCH, DELETE…) is incompatible with
an API strategy.
INFRASTRUCTURE
POST https://api.hotel.com/orders
 201 Created
 Location: https://api.hotel.com/orders/768
POST https://api.travel.com/orders
 500
DELETE https://api.hotel.com/orders/768
2. Adopt an explicit resource design which reveals the underlying transaction.
For example, to make a money transfer between resource A and B, instead of calling:
PATCH /accounts/a {amount : balance-XX}
PATCH /accounts/b {amount : balance+XX}
Please note that ACID transactions are absolutely not mandatory. A good illustration to
keep in mind is that “Starbucks is not transactional!”:
You order, then you pay, then you get your drink. If something goes wrong between the
two operations (which probably happens in 0.01% of all purchases) you’ll deal with a
compensating action.
You should not design an architecture based on exceptional behaviors.
WAF
WAF
You could design a «transfer» resource that would allow:
POST /transfers {acc1 : a, acc2 : b, amount : XX}
An asynchronous batch could have also triggered an email to the user: “Sorry, your order
could not be completed…” and revert to previous successful operations.
1. Use compensating actions by checking resource state, or request response, and
implementing rollback logic inside API consumer.
For example, to book an hotel room and a plane ticket on two different providers:
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

API
security.
All requests (OAuth2, IDP, API) must be secured with TLS (RFC5246).

TLS provides confidentiality via encryption.

TLS provides data integrity via keyed MAC (SHA-256).
HTTPS
API_KEY should be used to authorize client (application) on public resources
OAuth2 (RFC6749) should be used to authorize both client (application) and users
on private API resources.
OAuth 1.0 (RFC5849) is now obsolete as OAuth2 brought two major improvements:

Digital signature of requests were replaced by TLS.

OAuth2 supports any kind of device (native, web browser, servers…).
Keep in mind that OAuth2 is mandatory to protect private resources (e.g. when the
end user needs to be authenticated with a login screen):
AUTHORIZATION
/customers/007?client_id=API_KEY –H
‘“Authorization”:”Bearer X.Y.Z”’
/customers/007/accounts?client_id=API_KEY –H
‘“Authorization”:”Bearer X.Y.Z”’
OAuth2 is not mandatory for public resources. Client Credentials flow can be used
if you wish to protect all your endpoints with OAuth2. But an API_KEY is sufficient
for public resources:
/products?client_id=API_KEY
OpenID Connect protocol could be used to authenticate both client (application)
and user on private API resources.
Once in place, OpenID Connect allows you:

to manage your own OAuth2 instance to authorize access to API resources,

to use your own OpenID Connect provider to authenticate users,

to use any external OpenID Connect provider to authenticate users: Google,
Facebook and so on…
Web Giants will probably handle authentication better than you ever can: two-factor
authentication with sms…
AUTHENTICATION

If you are targeting “Digital”, you should not consider any other protocol: OAuth1,
SAML2, etc. “OpenID Connect was designed to also support native apps and mobile
applications, whereas SAML was designed only for Web-based applications”.

Do not use encryption/signatures on the applicative side.

Do not implement custom security solutions.

A handy way of avoiding implementing your own OAuth2 provider is to use an out-
of-the-box implementation.
COMMON
PITFALLS
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

API team
organization
Your API strategy will impact your teams and organization
As Conway’s Law says: “Any organization that designs a system [...] will inevitably produce a design whose structure is a copy
of the organization’s communication structure”.
You should organize your teams as you would like your IT system to be.
You should consider a small autonomous and empowered agile team to build your API. Let’s call it the API squad.
When you are building yourAPI, you generally create anAPI squad to set up some
CORE functionalities that need to be centralized:

API Management portal.

Developer portal.

OAuth2 or OpenID Connect.
This team could set up the first set of API resources to validate the API MVP, with
a façade pattern, and that’s OK.
The API squad should include all members that are responsible for it, typically:

A Product Owner from Business or Marketing.

Developers (optionally a Technical Leader).

OPS.

When it make sense, a Community Manager.
The total team members should not exceed 10.
API MVP
API SQUAD
STAGE ONE
When the MVP is validated, you should switch to a microservices pattern (see
“API integration patterns”).
In order to scale, the first API team remains and continues to be responsible for
the global API:

The Product Owner ensures that the API is consistent.

The role of the Community Manager increases.
Other resource provider teams have to be set up as needed using the same
model. The API team “delegates” and coaches resource provider squads (REST,
API design…). Each CORE IT component publishes REST resources that it is
accountable for. API façade is progressively decommissioned.
SCALING API
API SQUAD
STAGE TWO
RESSOURCE
PROVIDER
SQUAD
RESSOURCE
PROVIDER
SQUAD
RESSOURCE
PROVIDER
SQUAD
stage stage
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

BUSINESS ANALYSTS [Business]
Co-design API resources
Write automated functional
tests (TDR)
PRODUCT OWNER [Business]
Sync development with other teams
Responsible for API success
Define Follow-up indicators
COMMUNITY MANAGER [Marketing]
Drive External Developers (API users)
Social networking
API Evangelist
Administrate developer portal
OPS [IT]
Automated testing
Automated deployment
Scalability (elasticity) and SLA
DEVELOPERS [IT]
Design  develop API resources
Write API documentation
Measure and improve API performance
Write unit automated test
TECH-LEAD [IT]
Design  develop API resources
Write API documentation
Measure and improve API performance
Write unit automated test
API SQUAD
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

API management.
API Management solutions generally
offer the four following features:
Common pitfalls
1. An API Management tool is not a Golden
Hammer.
API Strategies are often summarised as “buying
the right API Management product”. This
reference card enumerates several aspects that
should be addressed in an API strategy. These
aspects concern three levels (functional,
technical, organizational).
API Management products address at most 20%
of API Strategies stakes.
2. Implementing an API façade with an API
façade solution (ESB) as a target architecture.
Editors often focus on the façade feature (e.g.
ESB, Gateway), but they should focus on
Managing your API. Your API should be built with
specific developments.
1. API MANAGEMENT PORTAL
Users enrolment
Publication / versioning
Usage statistics
Quotas
2.
DEVELOPER PORTAL
Self-enrolment
API Doc / Try-it interface
3. SECURITY
API_KEY
OAuth2 / OIDC
4. API FAÇADE
(ESB)
complicated
use with caution
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

Build
vs Buy.
You should distinguish between building your
API from managing your API.
API - BUILD
The API becomes the main entry point
to your CORE IT

Critical  differentiating components

A Key to a competitive advantage
ESB are ineffective to build good API
PORTALS  SECURITY - BUY

API Management portal

Developer portal

Security
Strategic assets
and fast innovation
Cheaper
resources
BUY
BUILD
BPO*
Common to all companies
Perceived as a resource
Common to all
companies in the sector
Perceived as a production asset
Unique,
differentiating
Perceived as a
competitive
advantage
*Business Process Outsourcing
BUILD
BUY!
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

API integration
patterns.
TO CREATE YOUR API, THERE ARE TWO INTEGRATION PATTERNS TO CONSIDER:
1. Façade pattern
The “façade” pattern is used to provide a simplified interface (API) to hide the complexity of your system.
This pattern can actually be implemented in two ways:
with a product (Buy) or with custom development (Build)
2. Microservices pattern (a key feature of Web-Oriented-Architecture)
PRE-BUILT FAÇADE PATTERN CUSTOM FAÇADE PATTERN MICROSERVICES PATTERN
Use an API Management (actually an
ESB) to expose a REST API based on
existing services.
Develop a custom App (Proxy) that will
provide a REST API based on existing
services.
This pattern consists to rebuild pro-
gressively your existing referentials to
expose a pure RESTful API, directly
from your CORE IT systems.
+ 
Short time to market
(good for a MVP)
+ Short time to market (good for a MVP).
+ Not dependent on an editor.
+ 
Will handle the complexity of your
business logic.
+ Not dependent on an editor.
+ 
Will handle the complexity of your
business logic.
+ No performance overhead.
- 
Dependent on the API Management/
ESB editor.
- 
May not handle the complexity of your
business logic.
- 
A performance overhead should be
considered.
- The API Management/ESB and your
existing service become highly coupled.
- 
A performance overhead should be
considered.
- 
The façade and your existing services
become highly coupled.
- Not time to market for your API MVP.
WHICH PATTERN SHOULD I USE?
In most cases, a “façade pattern” is actually an anti-pattern, that
was widely used to implement SOA with ESB.
You should consider façade pattern as a transitional solution, never
as a final one. The façade constrains are:

The resulting API will be limited by your underlying back-end
services: ”A great API on bad services is lipstick on a pig”!

A bottleneck API team not adapted to “scale API”.

The team will not handle the complexity of CORE IT business logic.

The façade will be tightly coupled to existing back-ends.
Ex: if a CORE system evolves, the façade is impacted.

With time, the API façade will become a huge monolith hard to
maintain.

Response time overhead.
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

OCTO Technology
“ Dans un monde complexe aux ressources finies, nous recherchons ensemble de meilleures
façons d'agir. Nous œuvrons à concevoir et à réaliser les produits numériques essentiels au
progrès de nos clients et à l'émergence d'écosystèmes vertueux”
– Manifeste OCTO Technology -
CABINET DE CONSEIL ET DE RÉALISATION IT
Paris
Toulouse
Hauts-de-France
IMPLANTATIONS
1OOO
OCTOS
OCTO EN TÊTE
DU PALMARÈS
3 CONFÉRENCES
FORMATION
La conférence tech par OCTO
3
6x
octo.com
AP
I
ARC
H
I
T
ECT
U
RE
ST
RAT
EGY

© OCTO Technology 2016
Les informations contenues dans ce document présentent le point de vue
actuel d'OCTO Technology sur les sujets évoqués, à la date de publication.
Tout extrait ou diffusion partielle est interdit sans l'autorisation préalable
d'OCTO Technology.
Les noms de produits ou de sociétés cités dans ce document peuvent être
les marques déposées par leurs propriétaires respectifs.
Conçu, réalisé et édité par OCTO Technology.

More Related Content

What's hot

Apache Kafka in the Automotive Industry (Connected Vehicles, Manufacturing 4....
Apache Kafka in the Automotive Industry (Connected Vehicles, Manufacturing 4....Apache Kafka in the Automotive Industry (Connected Vehicles, Manufacturing 4....
Apache Kafka in the Automotive Industry (Connected Vehicles, Manufacturing 4....Kai Wähner
 
How to Execute a Successful API Strategy
How to Execute a Successful API StrategyHow to Execute a Successful API Strategy
How to Execute a Successful API StrategyMatt McLarty
 
What do you mean by “API as a Product”?
What do you mean by “API as a Product”?What do you mean by “API as a Product”?
What do you mean by “API as a Product”?Nordic APIs
 
API Frenzy: API Strategy 101
API Frenzy: API Strategy 101API Frenzy: API Strategy 101
API Frenzy: API Strategy 101Akana
 
Cisco and AppDynamics: Redefining Application Intelligence - AppD Summit Europe
Cisco and AppDynamics: Redefining Application Intelligence - AppD Summit EuropeCisco and AppDynamics: Redefining Application Intelligence - AppD Summit Europe
Cisco and AppDynamics: Redefining Application Intelligence - AppD Summit EuropeAppDynamics
 
API Management Within a Microservices Architecture
API Management Within a Microservices Architecture API Management Within a Microservices Architecture
API Management Within a Microservices Architecture Nadeesha Gamage
 
Machine Learning Platformization & AutoML: Adopting ML at Scale in the Enterp...
Machine Learning Platformization & AutoML: Adopting ML at Scale in the Enterp...Machine Learning Platformization & AutoML: Adopting ML at Scale in the Enterp...
Machine Learning Platformization & AutoML: Adopting ML at Scale in the Enterp...Ed Fernandez
 
Architecting an Enterprise API Management Strategy
Architecting an Enterprise API Management StrategyArchitecting an Enterprise API Management Strategy
Architecting an Enterprise API Management StrategyWSO2
 
Journey To Cloud – Arrive First with ServiceNow and Accenture
Journey To Cloud – Arrive First with ServiceNow and AccentureJourney To Cloud – Arrive First with ServiceNow and Accenture
Journey To Cloud – Arrive First with ServiceNow and AccentureAccenture Operations
 
Agile Integration eBook from 2018
Agile Integration eBook from 2018Agile Integration eBook from 2018
Agile Integration eBook from 2018Kim Clark
 
Industry X.0 - Realizing Digital Value in Industrial Sectors
Industry X.0 - Realizing Digital Value in Industrial SectorsIndustry X.0 - Realizing Digital Value in Industrial Sectors
Industry X.0 - Realizing Digital Value in Industrial Sectorsaccenture
 
Using AIOps to reduce incidents volume
Using AIOps to reduce incidents volumeUsing AIOps to reduce incidents volume
Using AIOps to reduce incidents volumeAmazon Web Services
 
apidays Paris 2022 - Generating APIs from business models, Frederic Fontanet,...
apidays Paris 2022 - Generating APIs from business models, Frederic Fontanet,...apidays Paris 2022 - Generating APIs from business models, Frederic Fontanet,...
apidays Paris 2022 - Generating APIs from business models, Frederic Fontanet,...apidays
 
Api led connectivity_brazil
Api led connectivity_brazilApi led connectivity_brazil
Api led connectivity_brazilAnupam Gogoi
 
Top Trends in Application Architecture That Enable.pdf
Top Trends in Application Architecture That Enable.pdfTop Trends in Application Architecture That Enable.pdf
Top Trends in Application Architecture That Enable.pdfMantoshKumarSingh7
 
Api management best practices with wso2 api manager
Api management best practices with wso2 api managerApi management best practices with wso2 api manager
Api management best practices with wso2 api managerChanaka Fernando
 
Microservice Architecture | Microservices Tutorial for Beginners | Microservi...
Microservice Architecture | Microservices Tutorial for Beginners | Microservi...Microservice Architecture | Microservices Tutorial for Beginners | Microservi...
Microservice Architecture | Microservices Tutorial for Beginners | Microservi...Edureka!
 

What's hot (20)

Apache Kafka in the Automotive Industry (Connected Vehicles, Manufacturing 4....
Apache Kafka in the Automotive Industry (Connected Vehicles, Manufacturing 4....Apache Kafka in the Automotive Industry (Connected Vehicles, Manufacturing 4....
Apache Kafka in the Automotive Industry (Connected Vehicles, Manufacturing 4....
 
How to Execute a Successful API Strategy
How to Execute a Successful API StrategyHow to Execute a Successful API Strategy
How to Execute a Successful API Strategy
 
What do you mean by “API as a Product”?
What do you mean by “API as a Product”?What do you mean by “API as a Product”?
What do you mean by “API as a Product”?
 
API Frenzy: API Strategy 101
API Frenzy: API Strategy 101API Frenzy: API Strategy 101
API Frenzy: API Strategy 101
 
Cisco and AppDynamics: Redefining Application Intelligence - AppD Summit Europe
Cisco and AppDynamics: Redefining Application Intelligence - AppD Summit EuropeCisco and AppDynamics: Redefining Application Intelligence - AppD Summit Europe
Cisco and AppDynamics: Redefining Application Intelligence - AppD Summit Europe
 
API Management Within a Microservices Architecture
API Management Within a Microservices Architecture API Management Within a Microservices Architecture
API Management Within a Microservices Architecture
 
Machine Learning Platformization & AutoML: Adopting ML at Scale in the Enterp...
Machine Learning Platformization & AutoML: Adopting ML at Scale in the Enterp...Machine Learning Platformization & AutoML: Adopting ML at Scale in the Enterp...
Machine Learning Platformization & AutoML: Adopting ML at Scale in the Enterp...
 
Architecting an Enterprise API Management Strategy
Architecting an Enterprise API Management StrategyArchitecting an Enterprise API Management Strategy
Architecting an Enterprise API Management Strategy
 
Journey To Cloud – Arrive First with ServiceNow and Accenture
Journey To Cloud – Arrive First with ServiceNow and AccentureJourney To Cloud – Arrive First with ServiceNow and Accenture
Journey To Cloud – Arrive First with ServiceNow and Accenture
 
Agile Integration eBook from 2018
Agile Integration eBook from 2018Agile Integration eBook from 2018
Agile Integration eBook from 2018
 
Industry X.0 - Realizing Digital Value in Industrial Sectors
Industry X.0 - Realizing Digital Value in Industrial SectorsIndustry X.0 - Realizing Digital Value in Industrial Sectors
Industry X.0 - Realizing Digital Value in Industrial Sectors
 
API Governance in the Enterprise
API Governance in the EnterpriseAPI Governance in the Enterprise
API Governance in the Enterprise
 
Using AIOps to reduce incidents volume
Using AIOps to reduce incidents volumeUsing AIOps to reduce incidents volume
Using AIOps to reduce incidents volume
 
apidays Paris 2022 - Generating APIs from business models, Frederic Fontanet,...
apidays Paris 2022 - Generating APIs from business models, Frederic Fontanet,...apidays Paris 2022 - Generating APIs from business models, Frederic Fontanet,...
apidays Paris 2022 - Generating APIs from business models, Frederic Fontanet,...
 
Api led connectivity_brazil
Api led connectivity_brazilApi led connectivity_brazil
Api led connectivity_brazil
 
Top Trends in Application Architecture That Enable.pdf
Top Trends in Application Architecture That Enable.pdfTop Trends in Application Architecture That Enable.pdf
Top Trends in Application Architecture That Enable.pdf
 
Api management best practices with wso2 api manager
Api management best practices with wso2 api managerApi management best practices with wso2 api manager
Api management best practices with wso2 api manager
 
Architecture for the API-enterprise
Architecture for the API-enterpriseArchitecture for the API-enterprise
Architecture for the API-enterprise
 
Microservice Architecture | Microservices Tutorial for Beginners | Microservi...
Microservice Architecture | Microservices Tutorial for Beginners | Microservi...Microservice Architecture | Microservices Tutorial for Beginners | Microservi...
Microservice Architecture | Microservices Tutorial for Beginners | Microservi...
 
Why to Cloud Native
Why to Cloud NativeWhy to Cloud Native
Why to Cloud Native
 

Similar to RefCard API Architecture Strategy

Top 7 wrong common beliefs about Enterprise API implementation
Top 7 wrong common beliefs about Enterprise API implementationTop 7 wrong common beliefs about Enterprise API implementation
Top 7 wrong common beliefs about Enterprise API implementationOCTO Technology
 
Practical guide to building public APIs
Practical guide to building public APIsPractical guide to building public APIs
Practical guide to building public APIsReda Hmeid MBCS
 
Microservices&ap imanagement
Microservices&ap imanagementMicroservices&ap imanagement
Microservices&ap imanagementpramodkumards
 
Securely expose protected resources as ap is with app42 api gateway
Securely expose protected resources as ap is with app42 api gatewaySecurely expose protected resources as ap is with app42 api gateway
Securely expose protected resources as ap is with app42 api gatewayZuaib
 
MuleSoft London Community October 2017 - Hybrid and SAP Integration
MuleSoft London Community October 2017 - Hybrid and SAP IntegrationMuleSoft London Community October 2017 - Hybrid and SAP Integration
MuleSoft London Community October 2017 - Hybrid and SAP IntegrationPace Integration
 
A_Complete_Guide_to_API_Development.pdf
A_Complete_Guide_to_API_Development.pdfA_Complete_Guide_to_API_Development.pdf
A_Complete_Guide_to_API_Development.pdfPamRobert
 
WSO2Con Asia 2014 - Building the API-Centric Enterprise
WSO2Con Asia 2014 - Building the API-Centric EnterpriseWSO2Con Asia 2014 - Building the API-Centric Enterprise
WSO2Con Asia 2014 - Building the API-Centric EnterpriseWSO2
 
Extend soa with api management Sangam18
Extend soa with api management Sangam18Extend soa with api management Sangam18
Extend soa with api management Sangam18Vinay Kumar
 
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...apidays
 
An API (Application Programming Interface) is the means by which thi.pdf
An API (Application Programming Interface) is the means by which thi.pdfAn API (Application Programming Interface) is the means by which thi.pdf
An API (Application Programming Interface) is the means by which thi.pdfarakalamkah11
 
Understanding API Architectures: Web API vs. Minimal API – An In-Depth Compar...
Understanding API Architectures: Web API vs. Minimal API – An In-Depth Compar...Understanding API Architectures: Web API vs. Minimal API – An In-Depth Compar...
Understanding API Architectures: Web API vs. Minimal API – An In-Depth Compar...Polyxer Systems
 
Enterprise API deployment best practice
Enterprise API deployment best practiceEnterprise API deployment best practice
Enterprise API deployment best practiceSanjay Roy
 
Meetup 2022 - API Gateway landscape.pdf
Meetup 2022 - API Gateway landscape.pdfMeetup 2022 - API Gateway landscape.pdf
Meetup 2022 - API Gateway landscape.pdfRed Hat
 
2016 06 - design your api management strategy - axway - Api Management
2016 06 - design your api management strategy - axway - Api Management2016 06 - design your api management strategy - axway - Api Management
2016 06 - design your api management strategy - axway - Api ManagementSmartWave
 
APIs: the Glue of Cloud Computing
APIs: the Glue of Cloud ComputingAPIs: the Glue of Cloud Computing
APIs: the Glue of Cloud Computing3scale
 
API Best Practices
API Best PracticesAPI Best Practices
API Best PracticesSai Koppala
 
Best practices and advantages of REST APIs
Best practices and advantages of REST APIsBest practices and advantages of REST APIs
Best practices and advantages of REST APIsAparna Sharma
 
apidays New York 2023 - Enabling unified API Catalogs in a multi-vendor/cross...
apidays New York 2023 - Enabling unified API Catalogs in a multi-vendor/cross...apidays New York 2023 - Enabling unified API Catalogs in a multi-vendor/cross...
apidays New York 2023 - Enabling unified API Catalogs in a multi-vendor/cross...apidays
 

Similar to RefCard API Architecture Strategy (20)

Top 7 wrong common beliefs about Enterprise API implementation
Top 7 wrong common beliefs about Enterprise API implementationTop 7 wrong common beliefs about Enterprise API implementation
Top 7 wrong common beliefs about Enterprise API implementation
 
Octo API-days 2015
Octo API-days 2015Octo API-days 2015
Octo API-days 2015
 
Api design part 1
Api design part 1Api design part 1
Api design part 1
 
Practical guide to building public APIs
Practical guide to building public APIsPractical guide to building public APIs
Practical guide to building public APIs
 
Microservices&ap imanagement
Microservices&ap imanagementMicroservices&ap imanagement
Microservices&ap imanagement
 
Securely expose protected resources as ap is with app42 api gateway
Securely expose protected resources as ap is with app42 api gatewaySecurely expose protected resources as ap is with app42 api gateway
Securely expose protected resources as ap is with app42 api gateway
 
MuleSoft London Community October 2017 - Hybrid and SAP Integration
MuleSoft London Community October 2017 - Hybrid and SAP IntegrationMuleSoft London Community October 2017 - Hybrid and SAP Integration
MuleSoft London Community October 2017 - Hybrid and SAP Integration
 
A_Complete_Guide_to_API_Development.pdf
A_Complete_Guide_to_API_Development.pdfA_Complete_Guide_to_API_Development.pdf
A_Complete_Guide_to_API_Development.pdf
 
WSO2Con Asia 2014 - Building the API-Centric Enterprise
WSO2Con Asia 2014 - Building the API-Centric EnterpriseWSO2Con Asia 2014 - Building the API-Centric Enterprise
WSO2Con Asia 2014 - Building the API-Centric Enterprise
 
Extend soa with api management Sangam18
Extend soa with api management Sangam18Extend soa with api management Sangam18
Extend soa with api management Sangam18
 
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...
INTERFACE by apidays_What's your Type? Understanding API Types and Choosing t...
 
An API (Application Programming Interface) is the means by which thi.pdf
An API (Application Programming Interface) is the means by which thi.pdfAn API (Application Programming Interface) is the means by which thi.pdf
An API (Application Programming Interface) is the means by which thi.pdf
 
Understanding API Architectures: Web API vs. Minimal API – An In-Depth Compar...
Understanding API Architectures: Web API vs. Minimal API – An In-Depth Compar...Understanding API Architectures: Web API vs. Minimal API – An In-Depth Compar...
Understanding API Architectures: Web API vs. Minimal API – An In-Depth Compar...
 
Enterprise API deployment best practice
Enterprise API deployment best practiceEnterprise API deployment best practice
Enterprise API deployment best practice
 
Meetup 2022 - API Gateway landscape.pdf
Meetup 2022 - API Gateway landscape.pdfMeetup 2022 - API Gateway landscape.pdf
Meetup 2022 - API Gateway landscape.pdf
 
2016 06 - design your api management strategy - axway - Api Management
2016 06 - design your api management strategy - axway - Api Management2016 06 - design your api management strategy - axway - Api Management
2016 06 - design your api management strategy - axway - Api Management
 
APIs: the Glue of Cloud Computing
APIs: the Glue of Cloud ComputingAPIs: the Glue of Cloud Computing
APIs: the Glue of Cloud Computing
 
API Best Practices
API Best PracticesAPI Best Practices
API Best Practices
 
Best practices and advantages of REST APIs
Best practices and advantages of REST APIsBest practices and advantages of REST APIs
Best practices and advantages of REST APIs
 
apidays New York 2023 - Enabling unified API Catalogs in a multi-vendor/cross...
apidays New York 2023 - Enabling unified API Catalogs in a multi-vendor/cross...apidays New York 2023 - Enabling unified API Catalogs in a multi-vendor/cross...
apidays New York 2023 - Enabling unified API Catalogs in a multi-vendor/cross...
 

More from OCTO Technology

Le Comptoir OCTO - Se conformer à la CSRD : un levier d'action insoupçonné
Le Comptoir OCTO - Se conformer à la CSRD : un levier d'action insoupçonnéLe Comptoir OCTO - Se conformer à la CSRD : un levier d'action insoupçonné
Le Comptoir OCTO - Se conformer à la CSRD : un levier d'action insoupçonnéOCTO Technology
 
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloudLe Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloudOCTO Technology
 
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...OCTO Technology
 
La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...
La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...
La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...OCTO Technology
 
Le Comptoir OCTO - Maîtriser le RAG : connecter les modèles d’IA génératives ...
Le Comptoir OCTO - Maîtriser le RAG : connecter les modèles d’IA génératives ...Le Comptoir OCTO - Maîtriser le RAG : connecter les modèles d’IA génératives ...
Le Comptoir OCTO - Maîtriser le RAG : connecter les modèles d’IA génératives ...OCTO Technology
 
OCTO Talks - Les IA s'invitent au chevet des développeurs
OCTO Talks - Les IA s'invitent au chevet des développeursOCTO Talks - Les IA s'invitent au chevet des développeurs
OCTO Talks - Les IA s'invitent au chevet des développeursOCTO Technology
 
OCTO Talks - Lancement du livre Culture Test
OCTO Talks - Lancement du livre Culture TestOCTO Talks - Lancement du livre Culture Test
OCTO Talks - Lancement du livre Culture TestOCTO Technology
 
Le Comptoir OCTO - Green AI, comment éviter que votre votre potion magique d’...
Le Comptoir OCTO - Green AI, comment éviter que votre votre potion magique d’...Le Comptoir OCTO - Green AI, comment éviter que votre votre potion magique d’...
Le Comptoir OCTO - Green AI, comment éviter que votre votre potion magique d’...OCTO Technology
 
OCTO Talks - State of the art Architecture dans les frontend web
OCTO Talks - State of the art Architecture dans les frontend webOCTO Talks - State of the art Architecture dans les frontend web
OCTO Talks - State of the art Architecture dans les frontend webOCTO Technology
 
Comptoir OCTO ALD Automotive/Leaseplan
Comptoir OCTO ALD Automotive/LeaseplanComptoir OCTO ALD Automotive/Leaseplan
Comptoir OCTO ALD Automotive/LeaseplanOCTO Technology
 
Le Comptoir OCTO - Comment optimiser les stocks en linéaire par la Data ?
Le Comptoir OCTO - Comment optimiser les stocks en linéaire par la Data ? Le Comptoir OCTO - Comment optimiser les stocks en linéaire par la Data ?
Le Comptoir OCTO - Comment optimiser les stocks en linéaire par la Data ? OCTO Technology
 
Le Comptoir OCTO - Retour sur 5 ans de mise en oeuvre : Comment le RGPD a réi...
Le Comptoir OCTO - Retour sur 5 ans de mise en oeuvre : Comment le RGPD a réi...Le Comptoir OCTO - Retour sur 5 ans de mise en oeuvre : Comment le RGPD a réi...
Le Comptoir OCTO - Retour sur 5 ans de mise en oeuvre : Comment le RGPD a réi...OCTO Technology
 
Le Comptoir OCTO - Affinez vos forecasts avec la planification distribuée et...
Le Comptoir OCTO -  Affinez vos forecasts avec la planification distribuée et...Le Comptoir OCTO -  Affinez vos forecasts avec la planification distribuée et...
Le Comptoir OCTO - Affinez vos forecasts avec la planification distribuée et...OCTO Technology
 
Le Comptoir OCTO - La formation au cœur de la stratégie d’éco-conception
Le Comptoir OCTO - La formation au cœur de la stratégie d’éco-conceptionLe Comptoir OCTO - La formation au cœur de la stratégie d’éco-conception
Le Comptoir OCTO - La formation au cœur de la stratégie d’éco-conceptionOCTO Technology
 
Le Comptoir OCTO - Une vision de plateforme sans leadership tech n’est qu’hal...
Le Comptoir OCTO - Une vision de plateforme sans leadership tech n’est qu’hal...Le Comptoir OCTO - Une vision de plateforme sans leadership tech n’est qu’hal...
Le Comptoir OCTO - Une vision de plateforme sans leadership tech n’est qu’hal...OCTO Technology
 
Le Comptoir OCTO - L'avenir de la gestion du bilan carbone : les solutions E...
Le Comptoir OCTO - L'avenir de la gestion du bilan carbone :  les solutions E...Le Comptoir OCTO - L'avenir de la gestion du bilan carbone :  les solutions E...
Le Comptoir OCTO - L'avenir de la gestion du bilan carbone : les solutions E...OCTO Technology
 
Le Comptoir OCTO - Continuous discovery et continuous delivery pour construir...
Le Comptoir OCTO - Continuous discovery et continuous delivery pour construir...Le Comptoir OCTO - Continuous discovery et continuous delivery pour construir...
Le Comptoir OCTO - Continuous discovery et continuous delivery pour construir...OCTO Technology
 
RefCard Tests sur tous les fronts
RefCard Tests sur tous les frontsRefCard Tests sur tous les fronts
RefCard Tests sur tous les frontsOCTO Technology
 
RefCard RESTful API Design
RefCard RESTful API DesignRefCard RESTful API Design
RefCard RESTful API DesignOCTO Technology
 

More from OCTO Technology (20)

Le Comptoir OCTO - Se conformer à la CSRD : un levier d'action insoupçonné
Le Comptoir OCTO - Se conformer à la CSRD : un levier d'action insoupçonnéLe Comptoir OCTO - Se conformer à la CSRD : un levier d'action insoupçonné
Le Comptoir OCTO - Se conformer à la CSRD : un levier d'action insoupçonné
 
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloudLe Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
Le Comptoir OCTO - MLOps : Les patterns MLOps dans le cloud
 
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
La Grosse Conf 2024 - Philippe Stepniewski -Atelier - Live coding d'une base ...
 
La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...
La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...
La Grosse Conf 2024 - Philippe Prados - Atelier - RAG : au-delà de la démonst...
 
Le Comptoir OCTO - Maîtriser le RAG : connecter les modèles d’IA génératives ...
Le Comptoir OCTO - Maîtriser le RAG : connecter les modèles d’IA génératives ...Le Comptoir OCTO - Maîtriser le RAG : connecter les modèles d’IA génératives ...
Le Comptoir OCTO - Maîtriser le RAG : connecter les modèles d’IA génératives ...
 
OCTO Talks - Les IA s'invitent au chevet des développeurs
OCTO Talks - Les IA s'invitent au chevet des développeursOCTO Talks - Les IA s'invitent au chevet des développeurs
OCTO Talks - Les IA s'invitent au chevet des développeurs
 
OCTO Talks - Lancement du livre Culture Test
OCTO Talks - Lancement du livre Culture TestOCTO Talks - Lancement du livre Culture Test
OCTO Talks - Lancement du livre Culture Test
 
Le Comptoir OCTO - Green AI, comment éviter que votre votre potion magique d’...
Le Comptoir OCTO - Green AI, comment éviter que votre votre potion magique d’...Le Comptoir OCTO - Green AI, comment éviter que votre votre potion magique d’...
Le Comptoir OCTO - Green AI, comment éviter que votre votre potion magique d’...
 
OCTO Talks - State of the art Architecture dans les frontend web
OCTO Talks - State of the art Architecture dans les frontend webOCTO Talks - State of the art Architecture dans les frontend web
OCTO Talks - State of the art Architecture dans les frontend web
 
Refcard GraphQL
Refcard GraphQLRefcard GraphQL
Refcard GraphQL
 
Comptoir OCTO ALD Automotive/Leaseplan
Comptoir OCTO ALD Automotive/LeaseplanComptoir OCTO ALD Automotive/Leaseplan
Comptoir OCTO ALD Automotive/Leaseplan
 
Le Comptoir OCTO - Comment optimiser les stocks en linéaire par la Data ?
Le Comptoir OCTO - Comment optimiser les stocks en linéaire par la Data ? Le Comptoir OCTO - Comment optimiser les stocks en linéaire par la Data ?
Le Comptoir OCTO - Comment optimiser les stocks en linéaire par la Data ?
 
Le Comptoir OCTO - Retour sur 5 ans de mise en oeuvre : Comment le RGPD a réi...
Le Comptoir OCTO - Retour sur 5 ans de mise en oeuvre : Comment le RGPD a réi...Le Comptoir OCTO - Retour sur 5 ans de mise en oeuvre : Comment le RGPD a réi...
Le Comptoir OCTO - Retour sur 5 ans de mise en oeuvre : Comment le RGPD a réi...
 
Le Comptoir OCTO - Affinez vos forecasts avec la planification distribuée et...
Le Comptoir OCTO -  Affinez vos forecasts avec la planification distribuée et...Le Comptoir OCTO -  Affinez vos forecasts avec la planification distribuée et...
Le Comptoir OCTO - Affinez vos forecasts avec la planification distribuée et...
 
Le Comptoir OCTO - La formation au cœur de la stratégie d’éco-conception
Le Comptoir OCTO - La formation au cœur de la stratégie d’éco-conceptionLe Comptoir OCTO - La formation au cœur de la stratégie d’éco-conception
Le Comptoir OCTO - La formation au cœur de la stratégie d’éco-conception
 
Le Comptoir OCTO - Une vision de plateforme sans leadership tech n’est qu’hal...
Le Comptoir OCTO - Une vision de plateforme sans leadership tech n’est qu’hal...Le Comptoir OCTO - Une vision de plateforme sans leadership tech n’est qu’hal...
Le Comptoir OCTO - Une vision de plateforme sans leadership tech n’est qu’hal...
 
Le Comptoir OCTO - L'avenir de la gestion du bilan carbone : les solutions E...
Le Comptoir OCTO - L'avenir de la gestion du bilan carbone :  les solutions E...Le Comptoir OCTO - L'avenir de la gestion du bilan carbone :  les solutions E...
Le Comptoir OCTO - L'avenir de la gestion du bilan carbone : les solutions E...
 
Le Comptoir OCTO - Continuous discovery et continuous delivery pour construir...
Le Comptoir OCTO - Continuous discovery et continuous delivery pour construir...Le Comptoir OCTO - Continuous discovery et continuous delivery pour construir...
Le Comptoir OCTO - Continuous discovery et continuous delivery pour construir...
 
RefCard Tests sur tous les fronts
RefCard Tests sur tous les frontsRefCard Tests sur tous les fronts
RefCard Tests sur tous les fronts
 
RefCard RESTful API Design
RefCard RESTful API DesignRefCard RESTful API Design
RefCard RESTful API Design
 

Recently uploaded

Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...FIDO Alliance
 
Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024Victor Rentea
 
How to Check CNIC Information Online with Pakdata cf
How to Check CNIC Information Online with Pakdata cfHow to Check CNIC Information Online with Pakdata cf
How to Check CNIC Information Online with Pakdata cfdanishmna97
 
The Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightThe Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightSafe Software
 
Introduction to FIDO Authentication and Passkeys.pptx
Introduction to FIDO Authentication and Passkeys.pptxIntroduction to FIDO Authentication and Passkeys.pptx
Introduction to FIDO Authentication and Passkeys.pptxFIDO Alliance
 
DBX First Quarter 2024 Investor Presentation
DBX First Quarter 2024 Investor PresentationDBX First Quarter 2024 Investor Presentation
DBX First Quarter 2024 Investor PresentationDropbox
 
Working together SRE & Platform Engineering
Working together SRE & Platform EngineeringWorking together SRE & Platform Engineering
Working together SRE & Platform EngineeringMarcus Vechiato
 
Less Is More: Utilizing Ballerina to Architect a Cloud Data Platform
Less Is More: Utilizing Ballerina to Architect a Cloud Data PlatformLess Is More: Utilizing Ballerina to Architect a Cloud Data Platform
Less Is More: Utilizing Ballerina to Architect a Cloud Data PlatformWSO2
 
Event-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream ProcessingEvent-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream ProcessingScyllaDB
 
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)Paige Cruz
 
Simplifying Mobile A11y Presentation.pptx
Simplifying Mobile A11y Presentation.pptxSimplifying Mobile A11y Presentation.pptx
Simplifying Mobile A11y Presentation.pptxMarkSteadman7
 
WSO2 Micro Integrator for Enterprise Integration in a Decentralized, Microser...
WSO2 Micro Integrator for Enterprise Integration in a Decentralized, Microser...WSO2 Micro Integrator for Enterprise Integration in a Decentralized, Microser...
WSO2 Micro Integrator for Enterprise Integration in a Decentralized, Microser...WSO2
 
Portal Kombat : extension du réseau de propagande russe
Portal Kombat : extension du réseau de propagande russePortal Kombat : extension du réseau de propagande russe
Portal Kombat : extension du réseau de propagande russe中 央社
 
Six Myths about Ontologies: The Basics of Formal Ontology
Six Myths about Ontologies: The Basics of Formal OntologySix Myths about Ontologies: The Basics of Formal Ontology
Six Myths about Ontologies: The Basics of Formal Ontologyjohnbeverley2021
 
ERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage IntacctERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage IntacctBrainSell Technologies
 
The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...
The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...
The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...SOFTTECHHUB
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FMESafe Software
 
ChatGPT and Beyond - Elevating DevOps Productivity
ChatGPT and Beyond - Elevating DevOps ProductivityChatGPT and Beyond - Elevating DevOps Productivity
ChatGPT and Beyond - Elevating DevOps ProductivityVictorSzoltysek
 
Stronger Together: Developing an Organizational Strategy for Accessible Desig...
Stronger Together: Developing an Organizational Strategy for Accessible Desig...Stronger Together: Developing an Organizational Strategy for Accessible Desig...
Stronger Together: Developing an Organizational Strategy for Accessible Desig...caitlingebhard1
 

Recently uploaded (20)

Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
 
Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024
 
How to Check CNIC Information Online with Pakdata cf
How to Check CNIC Information Online with Pakdata cfHow to Check CNIC Information Online with Pakdata cf
How to Check CNIC Information Online with Pakdata cf
 
The Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and InsightThe Zero-ETL Approach: Enhancing Data Agility and Insight
The Zero-ETL Approach: Enhancing Data Agility and Insight
 
Introduction to FIDO Authentication and Passkeys.pptx
Introduction to FIDO Authentication and Passkeys.pptxIntroduction to FIDO Authentication and Passkeys.pptx
Introduction to FIDO Authentication and Passkeys.pptx
 
DBX First Quarter 2024 Investor Presentation
DBX First Quarter 2024 Investor PresentationDBX First Quarter 2024 Investor Presentation
DBX First Quarter 2024 Investor Presentation
 
Overview of Hyperledger Foundation
Overview of Hyperledger FoundationOverview of Hyperledger Foundation
Overview of Hyperledger Foundation
 
Working together SRE & Platform Engineering
Working together SRE & Platform EngineeringWorking together SRE & Platform Engineering
Working together SRE & Platform Engineering
 
Less Is More: Utilizing Ballerina to Architect a Cloud Data Platform
Less Is More: Utilizing Ballerina to Architect a Cloud Data PlatformLess Is More: Utilizing Ballerina to Architect a Cloud Data Platform
Less Is More: Utilizing Ballerina to Architect a Cloud Data Platform
 
Event-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream ProcessingEvent-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream Processing
 
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
 
Simplifying Mobile A11y Presentation.pptx
Simplifying Mobile A11y Presentation.pptxSimplifying Mobile A11y Presentation.pptx
Simplifying Mobile A11y Presentation.pptx
 
WSO2 Micro Integrator for Enterprise Integration in a Decentralized, Microser...
WSO2 Micro Integrator for Enterprise Integration in a Decentralized, Microser...WSO2 Micro Integrator for Enterprise Integration in a Decentralized, Microser...
WSO2 Micro Integrator for Enterprise Integration in a Decentralized, Microser...
 
Portal Kombat : extension du réseau de propagande russe
Portal Kombat : extension du réseau de propagande russePortal Kombat : extension du réseau de propagande russe
Portal Kombat : extension du réseau de propagande russe
 
Six Myths about Ontologies: The Basics of Formal Ontology
Six Myths about Ontologies: The Basics of Formal OntologySix Myths about Ontologies: The Basics of Formal Ontology
Six Myths about Ontologies: The Basics of Formal Ontology
 
ERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage IntacctERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage Intacct
 
The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...
The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...
The Ultimate Prompt Engineering Guide for Generative AI: Get the Most Out of ...
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
 
ChatGPT and Beyond - Elevating DevOps Productivity
ChatGPT and Beyond - Elevating DevOps ProductivityChatGPT and Beyond - Elevating DevOps Productivity
ChatGPT and Beyond - Elevating DevOps Productivity
 
Stronger Together: Developing an Organizational Strategy for Accessible Desig...
Stronger Together: Developing an Organizational Strategy for Accessible Desig...Stronger Together: Developing an Organizational Strategy for Accessible Desig...
Stronger Together: Developing an Organizational Strategy for Accessible Desig...
 

RefCard API Architecture Strategy

  • 2. octo.com AP I ARC H I T ECT U RE ST RAT EGY  API Levels. TheAPI level you are targeting can be reflected by the type of consumers you are addressing. The main difference lies in the way you need to “industrialize” the enrolment process and the quality required for your API. At Level 1, if an application developer faces an issue, he can directly meet the guys from the API team You should target Open API from the beginning (even if you are targeting Level 1 or 2 in the short term): So that you can fully industrialize the way developers consume your “services” on your developer portal: https://developers.fakecompany.com/ This is the only way to offer good enrolment, TTFAC* support in a digital way Level 1 « Internal API» API used by the company Level 2 « Partner API » API used by internal developers partner developers Level 3 « Open API » API used by internal developers, partner developers external developers As soon as we start working on an API, architecture issues arise. Many mistaken common beliefs turn out to be fiction in this area. A poorly designed API architecture will lead to misuse or – even worse – not be used at all by its intended clients: application developers. To facilitate and accelerate design and development of your APIs, we share our vision and beliefs with you in this Reference Card. They come from our direct experience on API projects. API Architecture Strategy.
  • 3. octo.com AP I ARC H I T ECT U RE ST RAT EGY  Integrating your legacy SOA implementations into your API Strategy… could end up with an URBANIZATION Strategy Monitoring, Accounting. Which API Strategy? Focusing on the REST approach inspired by Web Giants… may end up building a state of the Art API RESTful, Developer portal, TTFAC* DX**, X-device / X-channel. * “Time To First API Call” is the time a developer needs to consume the API in production after reading the documentation on the developer portal! We target 5 minutes. ** “Developer experience”. APIs are used by humans. We target a massive adoption, so we should craft them with love.
  • 4. octo.com AP I ARC H I T ECT U RE ST RAT EGY  Why an API strategy ? “Anytime,Anywhere,Any device” are the key problems of digitalisation. API is the answer to “Business Agility” as it allows to build rapidly new GUI for upcoming devices. An API layer enables Cross device Cross channel 360° customer view Open API allows To outsource innovation To create new business models Embrace WOA “Web Oriented Architecture” Build a fast, scalable secured REST API Based on: REST, HATEOAS, Stateless decoupled µ-services, Asynchronous patterns, OAuth2 and OpenID Connect protocols Leverage the power of your existing web infrastructure DISCLAMER This Reference Card does not claim to be 100% accurate. The design concepts shown here are a result of our previous work in the REST area. Please check out our blog http://blog.octo.com, and feel free to comment or challenge this API cookbook. We’re really looking forward to talking with you.
  • 5. octo.com AP I ARC H I T ECT U RE ST RAT EGY  API Big picture Architecture: From SOA to WOA. SOA (Service Oriented Architecture) fulfilled the promise of breaking down the monoliths but its implementation came with many pitfalls. WOA(WebOrientedArchitecture)isasubsetofSOAbasedonRESTfulmicroservices and tends to correct mistakes from past implementations.
  • 6. octo.com AP I ARC H I T ECT U RE ST RAT EGY  SOA* *SOAshouldn’t be confused with its past implementations. From 2000, the implementation is WS-*/SOAP at 99.% ARCHITECTURE Service oriented by design: multiple services can be provided, results in a huge number of services with slight variations depending on consumer needs. RPC approach: abstract of the distributed nature of the WWW network. MAJOR IMPLEMENTATIONS PROTOCOLS Heavyweight specific protocols (WS*). Use custom applicative protocols on top of HTTP and SOAP, that developers have to learn before calling any service. Security is based on a VPN or/and complex WS standard designed for server to server exchanges. INTEGRATION PATTERNS Often implemented through a façade pattern which consists of a monolithic bloc. Often concentrates complexity in the hands of a centralized ESB tool/team which has no ownership of business referentials. Often thinking by vendor tools first: ESB, BPM, BAM... CONSUMERS Clients are mostly servers.
  • 7. octo.com AP I ARC H I T ECT U RE ST RAT EGY  WOA ARCHITECTURE Resource-orientedbydesign:ensuresauniquerepresentationofeachresource, regardless of the number of consumers. Explicitly assumes the nature of the WWW network: strengths and weaknesses. MAJOR IMPLEMENTATIONS PROTOCOLS Simple and based on common Web standards (HTTP, URI, DNS…) used since the 90s. Use HTTP as the “universal” applicative protocol. No need to reinvent the wheel so that developers can quickly use APIs, which offer good affordance. Security is based on simple Web protocols, device-agnostic by design: OAuth2 and OpenID Connect. INTEGRATION PATTERNS Suits both a façade pattern and a microservices pattern (the last one being the true distributed nature of the Web). In a microservices implementation, each API team is fully responsible for their product:eachteamisresponsibleforthequality(SLA)oftheirresourcesinstead of putting it into an ESB. Think API First. CONSUMERS X-devices: clients are servers, native mobile apps, browsers…
  • 8. octo.com AP I ARC H I T ECT U RE ST RAT EGY  SOA SERVICE ORIENTED ARCHITECTURE SOAP Service A HTTP request HTML CSS JS Images APP. SERVER MVC Business Delegate APP. SERVER SOA Business Layer DATA Database FAKECOMPANY Centralized Business Logic accessible over the network - Often implemented with SOAP - Potentially can end up with a huge number of services with slight variations depending on consumer needs. getProductsA() getProductsA’() addProductToCart(1) updateStock() validCustomerPayment() completeOrder() ... App #1 App #2 Partner A SOAP Service A’ HTTP request Json over HTTP APP. SERVER REST proxy SOAP Services SOAP Services Multiple servers (one for each application) Partner A’
  • 9. octo.com AP I ARC H I T ECT U RE ST RAT EGY  WOA WEB ORIENTED ARCHITECTURE HTTP request HTTP status (+JSON +HATEOAS) APP. SERVER FAKECOMPANY µ SERVICES Independent resources Agnostic of consumers Potentially provided by different teams and technologies - GET /products - PATCH /carts/{product:1} - PATCH /stocks - POST /payments - PATCH /orders - ... (REST API based � services based) API Gateway https://api.fakecompany.com/v1/{resouces} DATA Database REST API /customers /prospects APP. SERVER DATA Database REST API /products /carts APP. SERVER DATA Database REST API /stocks APP. SERVER DATA Database REST API /payments RESTAPI - Centralized Business Logic accessible over the network - HTTP as the universal applicative protocol API Gateway - One single API entry-point - Monitoring, Throtting - 360° Customer View Partner App #3 REST REST REST REST App #1 App #2 ATAWAD - Web single PageApplications - Native Applications - ... Offer a consistent customer journey
  • 10. octo.com AP I ARC H I T ECT U RE ST RAT EGY  SOAP vs REST. Nick Gall Portfolio Design Lead at IBM / VP Gartner at Group “WS-* style Web Services are «Web» in name only… The W3C should extricate itself from further direct work on SOAP, WDSL, or any other WS-* specifications” 2007 - https://www.w3.org/2007/01/wos-papers/gall David Orchard Principal Engineer at @WalmartLabs / WS standards at BEA “Given the complexity of just SOAP and WSDL, how many developers will really be able to move to the full stack?... The promise of WSDL 2.0 has not materialized and is unlikely to do so” 2007 - https://www.w3.org/2007/01/wos-papers/bea Steve Loughran Apache Axis committer “The only place SOAP survives is in the enterprise because if you can control both ends of the conversation, you can use the same toolkit and eliminate interop” 2007 - http://www.1060.org/blogxter/ Antoine Chantalou Head of WOA API at OCTO Technology “By choosing REST and Web Oriented Architecture, you’re putting all the chances on your side to succeed in your API strategy… SOAP is an amazing example of how businesses can embrace complex architectures and solutions” 2015 - APIdays conference in Paris INTERVIEW SOAP SOAP VS REST: IT’S ABOUT ARCHITECTURE RPC SOAP Are operation/service oriented Tend to unify local and remote computation Are contract server oriented REST Is resource oriented Explicitly uses WEB distributed architecture Is developer oriented Simplicity wins again 2006 58% 29% 13% 2016 10% 6% 84% •REST •SOAP •Other Distribution of API protocols and styles, based on directory of APIs listed at ProgrammableWeb, May 2016. SOAP is Not Dead - It’s a Zombie in the Enterprise. Your API should be REST based
  • 11. octo.com AP I ARC H I T ECT U RE ST RAT EGY  API architecture stakes. You should build stateless resource providers. A stateless API provider is easier to distribute, scale and cache. Stateless doesn’t mean that there is no state. There are actually two kinds of state: Clienthandlesapplication/sessionstate:whereyou are in the interaction, navigation, session. Server handles only resource state and no session. Each request is self-contained. STATELESS A request should always offer low latency. An acceptable response time could be 200ms. 1. On a functional level: You should switch to an asynchronous flow if response times exceed the limit you consider acceptable. This limit could be 1s. Technically, the resource provider queues the request and sends 202 response to the client. PATCH /orders/007 -d ‘{“status”=“complete”}’ 202 Accepted When the request is processed, the user is informed by another channel: HTTP2 server push, websocket, email, sms, or polling. Asynchronous processing may have heavy impacts on business workflows. 2. On a technical level: Requests sent by the client should always be asynchronous (XHR for browser’s app). The resource provider may be asynchronous (see non-blocking/reactive architectures). You will get a system that is concurrent by design. Microservices is a key feature of Web OrientedArchitectures.At some point, you may consider splitting your CORE IT systems into decoupled medium-grained microser- vices. Medium grained microservices would be: each resource provider is responsible for a set of resources that are functionally related Fine grained microservices would be: each resource provider is responsible for one resource Business technological stakes are: Short TTM adaptability Keep complexity under control • Small and manageable resource providers • Limited component lifecycle synchronization Technology leveraging • Scalability performance • Appropriate technology for the right usage Note: if you decide to implement microservices, then this requires a compatible orga- nization and culture (small short-cycle teams and Devops). ASYNCHRONOUS MICROSERVICES
  • 12. octo.com AP I ARC H I T ECT U RE ST RAT EGY  With REST, you’ll have to drop transactions (from a client point of view). HTTP is not transactional. You may manage transactions with one the following solutions: NON- TRANSACTIONAL You may consider Cloud hosting over OnPremise hosting, as API should be as close as possible to users’ devices to provide an optimum response time: The “OAuth2 dance” to authenticate and authorize users involves several HTTP calls. Safe method calls should be cached with standard Web tools. A WAF RP should not be used. The following issues should be addressed by your API platform: DOS/DDOS protection is generally offered by cloud IaaS, PaaS platforms. Authentication, Authorization, Accounting is provided by OAuth2/OIDC. Confidentiality, Integrity is provided by TLS. An RP that forbids any HTTP methods (PUT, PATCH, DELETE…) is incompatible with an API strategy. INFRASTRUCTURE POST https://api.hotel.com/orders 201 Created Location: https://api.hotel.com/orders/768 POST https://api.travel.com/orders 500 DELETE https://api.hotel.com/orders/768 2. Adopt an explicit resource design which reveals the underlying transaction. For example, to make a money transfer between resource A and B, instead of calling: PATCH /accounts/a {amount : balance-XX} PATCH /accounts/b {amount : balance+XX} Please note that ACID transactions are absolutely not mandatory. A good illustration to keep in mind is that “Starbucks is not transactional!”: You order, then you pay, then you get your drink. If something goes wrong between the two operations (which probably happens in 0.01% of all purchases) you’ll deal with a compensating action. You should not design an architecture based on exceptional behaviors. WAF WAF You could design a «transfer» resource that would allow: POST /transfers {acc1 : a, acc2 : b, amount : XX} An asynchronous batch could have also triggered an email to the user: “Sorry, your order could not be completed…” and revert to previous successful operations. 1. Use compensating actions by checking resource state, or request response, and implementing rollback logic inside API consumer. For example, to book an hotel room and a plane ticket on two different providers:
  • 13. octo.com AP I ARC H I T ECT U RE ST RAT EGY  API security. All requests (OAuth2, IDP, API) must be secured with TLS (RFC5246). TLS provides confidentiality via encryption. TLS provides data integrity via keyed MAC (SHA-256). HTTPS API_KEY should be used to authorize client (application) on public resources OAuth2 (RFC6749) should be used to authorize both client (application) and users on private API resources. OAuth 1.0 (RFC5849) is now obsolete as OAuth2 brought two major improvements: Digital signature of requests were replaced by TLS. OAuth2 supports any kind of device (native, web browser, servers…). Keep in mind that OAuth2 is mandatory to protect private resources (e.g. when the end user needs to be authenticated with a login screen): AUTHORIZATION /customers/007?client_id=API_KEY –H ‘“Authorization”:”Bearer X.Y.Z”’ /customers/007/accounts?client_id=API_KEY –H ‘“Authorization”:”Bearer X.Y.Z”’ OAuth2 is not mandatory for public resources. Client Credentials flow can be used if you wish to protect all your endpoints with OAuth2. But an API_KEY is sufficient for public resources: /products?client_id=API_KEY OpenID Connect protocol could be used to authenticate both client (application) and user on private API resources. Once in place, OpenID Connect allows you: to manage your own OAuth2 instance to authorize access to API resources, to use your own OpenID Connect provider to authenticate users, to use any external OpenID Connect provider to authenticate users: Google, Facebook and so on… Web Giants will probably handle authentication better than you ever can: two-factor authentication with sms… AUTHENTICATION If you are targeting “Digital”, you should not consider any other protocol: OAuth1, SAML2, etc. “OpenID Connect was designed to also support native apps and mobile applications, whereas SAML was designed only for Web-based applications”. Do not use encryption/signatures on the applicative side. Do not implement custom security solutions. A handy way of avoiding implementing your own OAuth2 provider is to use an out- of-the-box implementation. COMMON PITFALLS
  • 14. octo.com AP I ARC H I T ECT U RE ST RAT EGY  API team organization Your API strategy will impact your teams and organization As Conway’s Law says: “Any organization that designs a system [...] will inevitably produce a design whose structure is a copy of the organization’s communication structure”. You should organize your teams as you would like your IT system to be. You should consider a small autonomous and empowered agile team to build your API. Let’s call it the API squad. When you are building yourAPI, you generally create anAPI squad to set up some CORE functionalities that need to be centralized: API Management portal. Developer portal. OAuth2 or OpenID Connect. This team could set up the first set of API resources to validate the API MVP, with a façade pattern, and that’s OK. The API squad should include all members that are responsible for it, typically: A Product Owner from Business or Marketing. Developers (optionally a Technical Leader). OPS. When it make sense, a Community Manager. The total team members should not exceed 10. API MVP API SQUAD STAGE ONE When the MVP is validated, you should switch to a microservices pattern (see “API integration patterns”). In order to scale, the first API team remains and continues to be responsible for the global API: The Product Owner ensures that the API is consistent. The role of the Community Manager increases. Other resource provider teams have to be set up as needed using the same model. The API team “delegates” and coaches resource provider squads (REST, API design…). Each CORE IT component publishes REST resources that it is accountable for. API façade is progressively decommissioned. SCALING API API SQUAD STAGE TWO RESSOURCE PROVIDER SQUAD RESSOURCE PROVIDER SQUAD RESSOURCE PROVIDER SQUAD stage stage
  • 15. octo.com AP I ARC H I T ECT U RE ST RAT EGY  BUSINESS ANALYSTS [Business] Co-design API resources Write automated functional tests (TDR) PRODUCT OWNER [Business] Sync development with other teams Responsible for API success Define Follow-up indicators COMMUNITY MANAGER [Marketing] Drive External Developers (API users) Social networking API Evangelist Administrate developer portal OPS [IT] Automated testing Automated deployment Scalability (elasticity) and SLA DEVELOPERS [IT] Design develop API resources Write API documentation Measure and improve API performance Write unit automated test TECH-LEAD [IT] Design develop API resources Write API documentation Measure and improve API performance Write unit automated test API SQUAD
  • 16. octo.com AP I ARC H I T ECT U RE ST RAT EGY  API management. API Management solutions generally offer the four following features: Common pitfalls 1. An API Management tool is not a Golden Hammer. API Strategies are often summarised as “buying the right API Management product”. This reference card enumerates several aspects that should be addressed in an API strategy. These aspects concern three levels (functional, technical, organizational). API Management products address at most 20% of API Strategies stakes. 2. Implementing an API façade with an API façade solution (ESB) as a target architecture. Editors often focus on the façade feature (e.g. ESB, Gateway), but they should focus on Managing your API. Your API should be built with specific developments. 1. API MANAGEMENT PORTAL Users enrolment Publication / versioning Usage statistics Quotas 2. DEVELOPER PORTAL Self-enrolment API Doc / Try-it interface 3. SECURITY API_KEY OAuth2 / OIDC 4. API FAÇADE (ESB) complicated use with caution
  • 17. octo.com AP I ARC H I T ECT U RE ST RAT EGY  Build vs Buy. You should distinguish between building your API from managing your API. API - BUILD The API becomes the main entry point to your CORE IT Critical differentiating components A Key to a competitive advantage ESB are ineffective to build good API PORTALS SECURITY - BUY API Management portal Developer portal Security Strategic assets and fast innovation Cheaper resources BUY BUILD BPO* Common to all companies Perceived as a resource Common to all companies in the sector Perceived as a production asset Unique, differentiating Perceived as a competitive advantage *Business Process Outsourcing BUILD BUY!
  • 18. octo.com AP I ARC H I T ECT U RE ST RAT EGY  API integration patterns. TO CREATE YOUR API, THERE ARE TWO INTEGRATION PATTERNS TO CONSIDER: 1. Façade pattern The “façade” pattern is used to provide a simplified interface (API) to hide the complexity of your system. This pattern can actually be implemented in two ways: with a product (Buy) or with custom development (Build) 2. Microservices pattern (a key feature of Web-Oriented-Architecture) PRE-BUILT FAÇADE PATTERN CUSTOM FAÇADE PATTERN MICROSERVICES PATTERN Use an API Management (actually an ESB) to expose a REST API based on existing services. Develop a custom App (Proxy) that will provide a REST API based on existing services. This pattern consists to rebuild pro- gressively your existing referentials to expose a pure RESTful API, directly from your CORE IT systems. + Short time to market (good for a MVP) + Short time to market (good for a MVP). + Not dependent on an editor. + Will handle the complexity of your business logic. + Not dependent on an editor. + Will handle the complexity of your business logic. + No performance overhead. - Dependent on the API Management/ ESB editor. - May not handle the complexity of your business logic. - A performance overhead should be considered. - The API Management/ESB and your existing service become highly coupled. - A performance overhead should be considered. - The façade and your existing services become highly coupled. - Not time to market for your API MVP. WHICH PATTERN SHOULD I USE? In most cases, a “façade pattern” is actually an anti-pattern, that was widely used to implement SOA with ESB. You should consider façade pattern as a transitional solution, never as a final one. The façade constrains are: The resulting API will be limited by your underlying back-end services: ”A great API on bad services is lipstick on a pig”! A bottleneck API team not adapted to “scale API”. The team will not handle the complexity of CORE IT business logic. The façade will be tightly coupled to existing back-ends. Ex: if a CORE system evolves, the façade is impacted. With time, the API façade will become a huge monolith hard to maintain. Response time overhead.
  • 19. octo.com AP I ARC H I T ECT U RE ST RAT EGY  OCTO Technology “ Dans un monde complexe aux ressources finies, nous recherchons ensemble de meilleures façons d'agir. Nous œuvrons à concevoir et à réaliser les produits numériques essentiels au progrès de nos clients et à l'émergence d'écosystèmes vertueux” – Manifeste OCTO Technology - CABINET DE CONSEIL ET DE RÉALISATION IT Paris Toulouse Hauts-de-France IMPLANTATIONS 1OOO OCTOS OCTO EN TÊTE DU PALMARÈS 3 CONFÉRENCES FORMATION La conférence tech par OCTO 3 6x
  • 20. octo.com AP I ARC H I T ECT U RE ST RAT EGY  © OCTO Technology 2016 Les informations contenues dans ce document présentent le point de vue actuel d'OCTO Technology sur les sujets évoqués, à la date de publication. Tout extrait ou diffusion partielle est interdit sans l'autorisation préalable d'OCTO Technology. Les noms de produits ou de sociétés cités dans ce document peuvent être les marques déposées par leurs propriétaires respectifs. Conçu, réalisé et édité par OCTO Technology.