Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
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
140
APIStrat 2016 | On-prem support? That was so 1982 (Charlie Ozinga)
apistrat
0
120
APIStrat 2016 | Effortless microservices in production with Kubernetes (Ken Wronkiewicz)
apistrat
0
160
Song by Tony Blank
apistrat
0
180
API Lifecycle Manager by Steve Fonseca
apistrat
2
250
APIs In The Enterprise: How Walgreens Formed It's Digital Business by Drew Schweinfurth
apistrat
1
380
Developers Are Difficult by Andrew Noonan
apistrat
0
130
Other Decks in Technology
See All in Technology
エンジニアリングをやめたくないので問い続ける
estie
2
1.2k
20251209_WAKECareer_生成AIを活用した設計・開発プロセス
syobochim
7
1.5k
Gemini でコードレビュー知見を見える化
zozotech
PRO
1
250
大企業でもできる!ボトムアップで拡大させるプラットフォームの作り方
findy_eventslides
1
770
MLflowで始めるプロンプト管理、評価、最適化
databricksjapan
1
220
会社紹介資料 / Sansan Company Profile
sansan33
PRO
11
390k
打 造 A I 驅 動 的 G i t H u b ⾃ 動 化 ⼯ 作 流 程
appleboy
0
330
Kiro Autonomous AgentとKiro Powers の紹介 / kiro-autonomous-agent-and-powers
tomoki10
0
480
エンジニアとPMのドメイン知識の溝をなくす、 AIネイティブな開発プロセス
applism118
4
1.3k
品質のための共通認識
kakehashi
PRO
3
260
.NET 10の概要
tomokusaba
0
110
AWS Security Agentの紹介/introducing-aws-security-agent
tomoki10
0
230
Featured
See All Featured
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
21
1.3k
Building a Scalable Design System with Sketch
lauravandoore
463
34k
Context Engineering - Making Every Token Count
addyosmani
9
510
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
122
21k
Java REST API Framework Comparison - PWX 2021
mraible
34
9k
Large-scale JavaScript Application Architecture
addyosmani
515
110k
Documentation Writing (for coders)
carmenintech
76
5.2k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.8k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
51k
Bash Introduction
62gerente
615
210k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
710
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