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
生成AI活用の組織格差を解消する 〜ビジネス職のCursor導入が開発効率に与えた好循環〜 / Closing the Organizational Gap in AI Adoption
upamune
7
5.3k
Tokyo_reInforce_2025_recap_iam_access_analyzer
hiashisan
0
190
React開発にStorybookとCopilotを導入して、爆速でUIを編集・確認する方法
yu_kod
1
280
AIの全社活用を推進するための安全なレールを敷いた話
shoheimitani
2
520
怖くない!はじめてのClaude Code
shinya337
0
400
ビズリーチが挑む メトリクスを活用した技術的負債の解消 / dev-productivity-con2025
visional_engineering_and_design
3
7.7k
さくらのIaaS基盤のモニタリングとOpenTelemetry/OSC Hokkaido 2025
fujiwara3
3
440
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
2
7.8k
Beyond Kaniko: Navigating Unprivileged Container Image Creation
f30
0
130
fukabori.fm 出張版: 売上高617億円と高稼働率を陰で支えた社内ツール開発のあれこれ話 / 20250704 Yoshimasa Iwase & Tomoo Morikawa
shift_evolve
PRO
2
7.8k
タイミーのデータモデリング事例と今後のチャレンジ
ttccddtoki
6
2.4k
赤煉瓦倉庫勉強会「Databricksを選んだ理由と、絶賛真っ只中のデータ基盤移行体験記」
ivry_presentationmaterials
2
360
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Being A Developer After 40
akosma
90
590k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
Done Done
chrislema
184
16k
Music & Morning Musume
bryan
46
6.6k
Statistics for Hackers
jakevdp
799
220k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Thoughts on Productivity
jonyablonski
69
4.7k
Producing Creativity
orderedlist
PRO
346
40k
4 Signs Your Business is Dying
shpigford
184
22k
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