Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Skeleton-free Closets: Designing internal APIs ...
Search
API Strategy & Practice Conference
September 26, 2014
Technology
1
220
Skeleton-free Closets: Designing internal APIs you can be proud of
by Matthew McClure @ APIStrat 2014 in Chicago
API Strategy & Practice Conference
September 26, 2014
Tweet
Share
More Decks by API Strategy & Practice Conference
See All by API Strategy & Practice Conference
APIStrat 2016 | The end of polling: why and how to transform a REST API into a Data Streaming API (Audrey Neveu)
apistrat
12
290
APIStrat 2016 | OpenAPI Trek: Beyond API Documentation (Arnaud Lauret)
apistrat
5
230
APIStrat 2016 | Flying Dreams: Real-Time Communication from the Edge of Space (Jonathan Barton, Neha Abrol)
apistrat
1
130
APIStrat 2016 | On-prem support? That was so 1982 (Charlie Ozinga)
apistrat
0
110
APIStrat 2016 | Effortless microservices in production with Kubernetes (Ken Wronkiewicz)
apistrat
0
150
Song by Tony Blank
apistrat
0
160
API Lifecycle Manager by Steve Fonseca
apistrat
2
230
APIs In The Enterprise: How Walgreens Formed It's Digital Business by Drew Schweinfurth
apistrat
1
370
Developers Are Difficult by Andrew Noonan
apistrat
0
130
Other Decks in Technology
See All in Technology
Reach American Airlines®️ Instantly: 19 Calling Methods for Fast Support in the USA
flyamerican
1
170
Beyond Kaniko: Navigating Unprivileged Container Image Creation
f30
0
130
2025-07-06 QGIS初級ハンズオン「はじめてのQGIS」
kou_kita
0
170
スタートアップに選択肢を 〜生成AIを活用したセカンダリー事業への挑戦〜
nstock
0
210
United Airlines Customer Service– Call 1-833-341-3142 Now!
airhelp
0
170
SaaS型なのに自由度の高い本格CMSでサイト構築と運用のコスパ&タイパUP! MovableType.net の便利機能とユーザー事例のご紹介
masakah
0
110
Lakebaseを使ったAIエージェントを実装してみる
kameitomohiro
0
130
Model Mondays S2E04: AI Developer Experiences
nitya
0
140
成長し続けるアプリのためのテストと設計の関係、そして意思決定の記録。
sansantech
PRO
0
120
ネットワーク保護はどう変わるのか?re:Inforce 2025最新アップデート解説
tokushun
0
210
DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所
soudai
PRO
50
20k
開発生産性を測る前にやるべきこと - 組織改善の実践 / Before Measuring Dev Productivity
kaonavi
10
4.7k
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Designing for humans not robots
tammielis
253
25k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Practical Orchestrator
shlominoach
189
11k
BBQ
matthewcrist
89
9.7k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
Rails Girls Zürich Keynote
gr2m
95
14k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Writing Fast Ruby
sferik
628
62k
Transcript
SKELETON FREE CLOSETS DESIGNING INTERNAL APIS YOU CAN BE PROUD
OF API STRATEGY & PRACTICE: CHICAGO, 2014 @matt_mcclure
None
THE RISE OF THE INTERNAL API
THEN: THE MONOLITH One application to rule them all.
NOW: MICROSERVICES A suite of small services that communicate.
(Or at least somewhere in between)
WHICH IS COOL! BUT...
THE TRUTH
MOST* INTERNAL APIS SUCK *Based on a highly scientific sampling
of my friends and colleagues
BUT WHY?
NOBODY THEM
WHAT SEEMS TO HAPPEN 1. There are two services (or
an application is broken up) 2. Need to glue these things together 3. Slap together an API interface 4. Functional? Done. 5.
[ACTUAL] EXAMPLE INTERACTION Me: “Do you have any examples of
a bad internal API?” Colleague: “Well, the other day I saw...” Me: “Perfect. Can you link me to the docs?” Colleague: *blank stare* Colleague: *laughter*
SO HOW CAN WE DO BETTER?
DESIGN FIRST Every. Single. Time.
BUT WHAT ABOUT... NO.
TOO MANY FOR EXCUSES ...or any text editor of
your choice.
GET COLLEAGUES INVOLVED Show design drafts to people who will
have to use it
IT TAKES AN ORGANIZATION Get * management involved as well
KICK BAD HABITS Your org is probably building bad internal
APIs because it's a habit now.
KILL YOUR DARLINGS It's good to have organization guidelines and
all, but...
DON'T CLING FOR CONSISTENCY SAKE If patterns / best practices
/ dev preferences change enough, change with them
AIM FOR IDIOMATIC Internal APIs should feel "standard" within the
broader context
DOCUMENT EVERYTHING Even Especially if you're not proud of it.
OWN UP TO SHORTCOMINGS Surprises are worse than idiosyncracies
KEEP IT UP TO DATE This is harder than it
seems. Admit it.
BE A GOOD CITIZEN Update documentation when you notice problems.
TL;DR INTERNAL != CUT CORNERS
THINK ABOUT FUTURE YOUS These APIs will potentially be
a communication layer for years.
THANK YOU
[email protected]
@matt_mcclure