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
ビジネス職が分析も担う事業部制組織でのデータ活用の仕組みづくり / Enabling Data Analytics in Business-Led Divisional Organizations
zaimy
1
400
サービスを止めるな! DDoS攻撃へのスマートな備えと最前線の事例
coconala_engineer
1
180
AWS 怖い話 WAF編 @fillz_noh #AWSStartup #AWSStartup_Kansai
fillznoh
0
130
Introduction to Sansan for Engineers / エンジニア向け会社紹介
sansan33
PRO
5
39k
OpenTelemetryセマンティック規約の恩恵とMackerel APMにおける活用例 / SRE NEXT 2025
mackerelio
3
2k
Microsoft Defender XDRで疲弊しないためのインシデント対応
sophiakunii
1
320
AIエージェントが書くのなら直接CloudFormationを書かせればいいじゃないですか何故AWS CDKを使う必要があるのさ
watany
18
7.6k
SRE with AI:実践から学ぶ、運用課題解決と未来への展望
yoshiiryo1
0
320
「現場で活躍するAIエージェント」を実現するチームと開発プロセス
tkikuchi1002
3
360
CDK Vibe Coding Fes
tomoki10
1
630
モニタリング統一への道のり - 分散モニタリングツール統合のためのオブザーバビリティプロジェクト
niftycorp
PRO
1
520
ABEMAの本番環境負荷試験への挑戦
mk2taiga
5
1.3k
Featured
See All Featured
Thoughts on Productivity
jonyablonski
69
4.7k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Being A Developer After 40
akosma
90
590k
The Invisible Side of Design
smashingmag
301
51k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Raft: Consensus for Rubyists
vanstee
140
7k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
990
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
We Have a Design System, Now What?
morganepeng
53
7.7k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
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