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
300
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
170
API Lifecycle Manager by Steve Fonseca
apistrat
2
240
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
テストを軸にした生き残り術
kworkdev
PRO
0
200
Agile PBL at New Grads Trainings
kawaguti
PRO
1
420
Evolución del razonamiento matemático de GPT-4.1 a GPT-5 - Data Aventura Summit 2025 & VSCode DevDays
lauchacarro
0
190
ChatGPTとPlantUML/Mermaidによるソフトウェア設計
gowhich501
1
130
AIのグローバルトレンド2025 #scrummikawa / global ai trend
kyonmm
PRO
1
280
S3アクセス制御の設計ポイント
tommy0124
3
200
RSCの時代にReactとフレームワークの境界を探る
uhyo
10
3.4k
大「個人開発サービス」時代に僕たちはどう生きるか
sotarok
20
9.9k
初めてAWSを使うときのセキュリティ覚書〜初心者支部編〜
cmusudakeisuke
1
240
オブザーバビリティが広げる AIOps の世界 / The World of AIOps Expanded by Observability
aoto
PRO
0
370
自作JSエンジンに推しプロポーザルを実装したい!
sajikix
1
170
allow_retry と Arel.sql / allow_retry and Arel.sql
euglena1215
1
160
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
51
5.6k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Producing Creativity
orderedlist
PRO
347
40k
The World Runs on Bad Software
bkeepers
PRO
70
11k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Visualization
eitanlees
148
16k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Writing Fast Ruby
sferik
628
62k
RailsConf 2023
tenderlove
30
1.2k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
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